Creating Build Forge build engines

A Build Forge build engine identifies the Build Forge Services Component for the Build Forge installation. Its identifier (engine ID) is typically the same as the Build Forge Services Component's machine name, so that it is easier to determine which Services Component is associated with which engine ID. You can associate the same build engine instance with multiple Build Forge build definitions. You can also associate more than one build engine against one build definition; for example to support fail-over.

Before you begin

You have a Rational® Build Forge® Services Component running, with a dedicated user account created.
Note: Requests related to the Build Forge integration are issued from the Jazz® Team Server (not client) to Build Forge. If there is a firewall between them, then it needs to be opened up, or it fails and produces the error message "ProtocolException exception occurred testing the connection" with messageKey=APIProtoCorrupted. The same error can occur if an invalid port is specified, if the port returns content (as opposed to connection refused, which would produce a different error).


  1. In the Team Artifacts view, in the project area, expand the Builds folder.
  2. Right-click Build Engines; then click New Build Engine.
  3. On the New Build Engine page, ensure that Create a new build engine is selected and click Next.
  4. On the General Information page, in the ID field, type a build engine identifier.
  5. In the Available build engine types pane, select Rational Build Forge and click Finish.
  6. In the Build Engine editor, click the Build Forge tab.
  7. Configure the connection settings by entering a host name, port, user name, and password in the appropriate fields.
    Note: These connection settings connect and authenticate to the Build Forge services layer component. By default, port 3966 is used for non-secure communications. Port 49150 is used when you select the Connect securely to Build Forge check box. The user name and password must already be configured in Build Forge and be dedicated to this Engineering Workflow Management instance. Do not use the same user name to authenticate to Build Forge from any other system, or the user experiences session conflicts. Also, when you configure the same user name on different build engines on this Build Forge instance, enter the host name consistently. For example, use the same fully qualified host name in all build engine configurations. Then, the host name can correctly retrieve an existing connection from the cache.

    If supported in your version of Build Forge, select API-Only as the user type. This action prevents login through the web client and minimizes the risk of session conflicts.

    Note: When you use LDAP authentication in the build engine editor, log in as domain_name\user_id. The best practice is to use a local user ID from the build server instead of an LDAP user ID. Contact your Build Forge administrator to obtain the domain name.
  8. Optional: To configure SSL:
    1. Create a folder named buildforge_conf. For Liberty server, create the buildforge_conf folder under LibertyInstallDir/servers/clm.
    2. Under the buildforge_conf folder, create a subfolder for each Build Forge deployment that you want to connect to securely. Use the naming convention hostname_port. For example, JazzInstallDir/server/buildforge_conf/ The host name must match the value on the Build Engine configuration page.
    3. Copy the bfclient.conf and buildforge truststore (p12 or jks) files from the Build Forge deployment into each Build Forge deployment subfolder.
      Note: The truststore files (p12 or jks) must be at the same level as bfclient.conf and the references to these files from bfclient.conf must use absolute paths.
      Note: Configure SSL in each CCM node in the cluster.
  9. Click Test Connection.
  10. Click Save.