Migrating a user-defined node

You must complete the following steps to migrate a user-defined node to WebSphere Event Broker Version 6.0:
  1. Migrating the Message Brokers Toolkit representation of the user-defined node
  2. Migrating the runtime user-defined node code

Migrating the Message Brokers Toolkit representation of the user-defined node

You can deploy a user-defined node that is written in the Version 5.0 Message Brokers Toolkit on the Version 6.0 Message Brokers Toolkit. Before you can deploy the user-defined node, you must migrate the Message Brokers Toolkit representation of the user-defined node to the Version 6.0 Message Brokers Toolkit.

To migrate from the Version 5.1 or Version 5.1Message Brokers Toolkit to the Version 6.0 Message Brokers Toolkit, complete the following steps:

  1. Import the user-defined node project into the Version 6.0 Message Brokers Toolkit.
  2. Select your user-defined node project in the Package Explorer, and click Project > Clean Project.

To migrate from the Version 5.0 Message Brokers Toolkit to the Version 6.0 Message Brokers Toolkit, complete the following steps:

  1. Import the user-defined node project into the Version 6.0 Message Brokers Toolkit.
  2. Select your user-defined node project in the Package Explorer, and click Project > Clean Project.
  3. Modify the <requires> element in the plugin.xml file in the user-defined node project root to match the following:
    <requires>
            <import match="greaterOrEqual" plugin="com.ibm.etools.mft.api" version="6.0.0"/>
    </requires>
  4. Modify the "org.eclipse.help.contexts" extension in the same plugin.xml file to match the following:
    <extension point="org.eclipse.help.contexts">
    	<contexts file="HelpContexts.xml"/>
    </extension>

When you have migrated your user-defined nodes, you do not need to migrate any message flows that contain the user-defined node.

You must now complete the step Migrating the runtime user-defined node code.

Migrating the runtime user-defined node code

To migrate the runtime user-defined node code, complete the following steps:

  1. Put a copy of your compiled or packaged user-defined extension file on every broker system from which you intend to use it.
    • If you are migrating a Java user-defined node, then you can build the user-defined extension file once and distribute it to each of your systems.
    • If you are migrating a C user-defined node and all of your brokers are of the same machine type, then you can build the user-defined extension file once and distribute it to each of your systems.
    • If you are migrating a C user-defined node and you have a cluster that consists of various machine types, for example one AIX, one Solaris, and one Windows broker, then you must build the files separately on each machine type.
  2. Specify the directory in which to put the file, by using either the mqsichangebroker or mqsicreatebroker command.

    In previous versions, the .lil or .jar file would be saved in the installation directory. Do not save the .lil or .jar file in the WebSphere Event Broker installation directory.

    For C user-defined extensions, store the .pdb file that corresponds to the .lil file, in the chosen directory. The .pdb file provides symbolic information that is used by WebSphere Event Broker when displaying stack diagnostic information in the event of access violations or other software malfunctions.

  3. Stop and start each broker. This is to ensure that the existence of a new file is detected.
    There are two situations where a broker restart is not necessary:
    • If you have created an execution group in the Message Brokers Toolkit, and there is nothing yet deployed to it, you can add the .lil, .pdb, and .jar file to your chosen directory.
    • If something has already been deployed to the execution group that you want to use, add the .lil, .pdb, or .jar file to your chosen directory and then use the mqsireload command to restart the group. It is not possible to overwrite an existing file on the Windows operating system when the broker is running because of the file lock that is put in place by the operating system.
    Use these two approaches with caution because any execution group that is connected to the same broker will also detect the new .lil, .pdb, and .jar files when that execution group is restarted, or when something is first deployed to that execution group. By using the more conventional way of restarting the broker, you ensure that anyone with an interest in a particular execution group is made aware that recent changes have been made to the broker.

    These two situations assume that you have already completed the previous step, and have therefore used either the mqsichangebroker command or the mqsicreatebroker command to notify the broker of the directory in which the user-defined extension files have been placed.

    When you have installed a user-defined node, it is referred to by its schema and name, just like a message flow.