To migrate data from Red Hat JBoss BPM Suite 5, do the following:

The repository is migrated at the specified destination.

Besides the -i command, you can also use -h to print out a help message and -f which forces an overwrite of the output directory, thus eliminating the need for manual deletion of this directory.

Importing the repository in Business Central

The repository can be imported in business central by cloning it. In the Administration perspective, click on the Repositories menu and then click on Clone Repository menu to start the process.

Importing the repository in JBDS

To import the repository in JBoss Developer Studio, do the following

To run Red Hat JBoss BPM Suite 5 processes in Red Hat JBoss BPM Suite 6, do the following:

Migrating to Version 6.1 and later

In version 6.1, 5.x APIs are no longer officially supported.

Red Hat JBoss BPM Suite no longer provides backward compatibility with the rule, event, and process application programming interface (API) from Red Hat JBoss RMS 5. The content of the knowledge-api JAR file is no longer supported in version 6.1 and onward, and is replaced by APIs contained in the kie-api JAR file that were introduced in Red Hat JBoss BPM Suite 6.0.

If you used the legacy 5.x API (located in knowledge-api.jar), please migrate (rewrite) the API calls to the new KIE API. Please be aware that several other APIs have changed between Red Hat JBoss RMS 5.x and Red Hat JBoss BPM Suite 6.x, namely the task service API and the REST API.

Migrating to Version 6.0

The Red Hat JBoss BPM Suite 6 system provides backward compatibility with the rule, event and process interactions from Red Hat JBoss RMS 5. You should eventually migrate (rewrite) these interactions to the all new revamped core API because this backward compatibility is likely to be deprecated.

If you cannot migrate your code to use the new API, then you can use the API provided by the purpose built knowledge-api jar for backwards compatible code. This API is the public interface for working with Red Hat JBoss BPM Suite and Red Hat JBoss RMS and is backwards compatible.

If you are instead using the REST API in Red Hat JBoss BPM Suite 5, note that this has changed as well and there is no mechanism in it for backwards compatibility.

As you know, there are two ways you can use Red Hat JBoss BRMS/Red Hat JBoss BPM Suite: in an embedded mode, or in a remote mode. In the embedded mode, you package the runtime libraries with your application and execute the BPMN processes in the same JVM. In the remote mode, the business assets are created, deployed and executed in the same server, but they are accessed via a remote client application using the REST or the JMS API.

Both of these modes presents different challenges when it comes to the migration. In this section we will focus on the migration for the remote usage of Red Hat JBoss BPM Suite with the help of a REST example.

REST API Example

This example shows how to:

The client side for Red Hat JBoss BRMS 5 can be created using the following code:

import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.HttpMethod;
import org.apache.commons.httpclient.NameValuePair;
import org.apache.commons.httpclient.methods.GetMethod;
import org.apache.commons.httpclient.methods.PostMethod;
import org.apache.commons.httpclient.methods.multipart.MultipartRequestEntity;
import org.apache.commons.httpclient.methods.multipart.Part;
import org.apache.commons.httpclient.methods.multipart.StringPart;
import org.jboss.bpm.console.client.model.ProcessDefinitionRef;
import org.jboss.bpm.console.client.model.ProcessDefinitionRefWrapper;
import org.jboss.bpm.console.client.model.ProcessInstanceRef;


 public class RestClientStartWithParam {
    private static final String BASE_URL = "http://localhost:8080/business-central-server/rs/";
    private static final String AUTH_URL = BASE_URL + "identity/secure/j_security_check";
    private final String username;
    private final String password;

    private static final String PROCESS_ID = "defaultPackage.hello";

    public RestClientStartWithParam(final String u, final String p) {
        this.username = u;
        this.password = p;
    }

    public static void main(String[] args) throws Exception {

        RestClientStartWithParam client = new RestClientStartWithParam("admin", "admin");

        // get process definitions
        ProcessDefinitionRefWrapper processDefinitionWrapper = client.getProcessDefinitions(client);

        // pick up "com.sample.bpmn.hello"
        ProcessDefinitionRef definitionRef = null;
        for (ProcessDefinitionRef processDefinitionRef : processDefinitionWrapper.getDefinitions()) {
            if (processDefinitionRef.getId().equals(PROCESS_ID)) {
                definitionRef = processDefinitionRef;
                break;
            }
        }
        if (definitionRef == null) {
            System.out.println(PROCESS_ID + " doesn't exist");
            return;
        }

        // start a process instance with parameters
        Map<String, String> params = new HashMap<String, String>();
        params.put("employee", "thomas");
        params.put("reason", "theReason");
        client.startProcessWithParameters(client, definitionRef, params);
    }

        private void startProcessWithParameters(RestClientStartWithParam client, ProcessDefinitionRef def,
            Map<String, String> params) throws Exception {
        String newInstanceUrl = BASE_URL + "form/process/" + def.getId() + "/complete";
        String dataFromService = client.getDataFromService(newInstanceUrl, "POST", params, true);

        System.out.println(dataFromService);
    }

    // get DataFromService method can be implemented like this

    private String getDataFromService(String urlpath, String method, Map<String, String> params, boolean multipart)
            throws Exception {
        HttpClient httpclient = new HttpClient();

        HttpMethod theMethod = null;
        StringBuffer sb = new StringBuffer();

        if ("GET".equalsIgnoreCase(method)) {
            theMethod = new GetMethod(urlpath);
        } else if ("POST".equalsIgnoreCase(method)) {
            theMethod = new PostMethod(urlpath);

            if (params != null) {

                if (multipart) {
                    List<Part> parts = new ArrayList<Part>();
                    for (String key : params.keySet()) {
                        StringPart stringPart = new StringPart(key, params.get(key));
                        stringPart.setCharSet("UTF-8");
                        parts.add(stringPart);
                    }
                    ((PostMethod) theMethod).setRequestEntity(new MultipartRequestEntity(parts.toArray(new Part[0]),
                            theMethod.getParams()));
                } else {

                    List<NameValuePair> nameValuePairList = new ArrayList<NameValuePair>();
                    for (String key : params.keySet()) {
                        nameValuePairList.add(new NameValuePair(key, params.get(key)));
                    }
                    ((PostMethod) theMethod).setRequestBody(nameValuePairList.toArray(new NameValuePair[0]));

                }
            }

        }

        if (username != null && password != null) {

            try {
                int result = httpclient.executeMethod(theMethod);
                System.out.println("result = " + result);
                // System.out.println(theMethod.getResponseBodyAsString());
            } catch (IOException e) {
                e.printStackTrace();
            } finally {
                theMethod.releaseConnection();
            }
            PostMethod authMethod = new PostMethod(AUTH_URL);
            NameValuePair[] data = { new NameValuePair("j_username", username),
                    new NameValuePair("j_password", password) };
            authMethod.setRequestBody(data);
            try {
                int result = httpclient.executeMethod(authMethod);
                System.out.println("result = " + result);
                // System.out.println(theMethod.getResponseBodyAsString());
            } catch (IOException e) {
                e.printStackTrace();
            } finally {
                authMethod.releaseConnection();
            }
        }

        try {
            int result = httpclient.executeMethod(theMethod);
            System.out.println("result = " + result);
            sb.append(theMethod.getResponseBodyAsString());
            String rawResult = sb.toString();
            return rawResult;

        } catch (Exception e) {
            throw e;
        } finally {
            theMethod.releaseConnection();
        }
    }

The Red Hat JBoss BRMS 5 endpoints are documented in BRMS 5.0 User Guide and BRMS 5.0 Business Process Management Guide.

As you can see, even this very simple example looks rather complex when implemented. The reason for this is partially that there is no native client for Red Hat JBoss BRMS 5 server. You can however choose the optional web client—​Apache HttpClient, RestEasy or even use just plain java.net libraries. This applies in Red Hat JBoss BPM Suite/BRMS 6 as well—​you can still choose the web client—​however, there is also a native java client provided for remote communication with version 6 which is much simpler to use.

Migrating to Red Hat JBoss BRMS/Red Hat JBoss BPM Suite 6

Let us migrate the same use case to Red Hat JBoss BPM Suite 6:

All of the available REST endpoints for Red Hat JBoss BRMS and Red Hat JBoss BPM Suite are documented here.

You can use either the Business Central remote API, or the Intelligent Process Server remote API. Unless you configure the Intelligent Process Server and Business Central to use the same data source, choose migration API based on what you are using at the moment. See chapter Unified Execution Servers of the Red Hat JBoss BPM Suite Administration and Configuration Guide for more details.

Intelligent Process Server API Example

To migrate using the Intelligent Process Server API, see the following example:

import java.util.HashMap;
import java.util.List;
import java.util.Map;

import org.kie.server.api.model.instance.TaskSummary;
import org.kie.server.client.KieServicesClient;
import org.kie.server.client.KieServicesConfiguration;
import org.kie.server.client.KieServicesFactory;
import org.kie.server.client.ProcessServicesClient;
import org.kie.server.client.UserTaskServicesClient;

public class Main {

    private static final String APP_URL = "http://localhost:8080/kie-server/services/rest/server";
    private static final String USER = "john";
    private static final String PASSWORD = "john";

    // Container ID in the Intelligent Process Server/Realtime Decision Server
    private static final String CONTAINER_ID = "sample-container";
    private static final String PROCESS_DEFINITION_ID = "sample-project.sample-process";

    public static void main(String[] args) {
        // Configuration can be used for additional settings, like timeout, marshalling format...
        KieServicesConfiguration configuration = KieServicesFactory.newRestConfiguration(APP_URL, USER, PASSWORD);
        KieServicesClient kieServicesClient = KieServicesFactory.newKieServicesClient(configuration);
        ProcessServicesClient processClient = kieServicesClient.getServicesClient(ProcessServicesClient.class);
        UserTaskServicesClient taskClient = kieServicesClient.getServicesClient(UserTaskServicesClient.class);

        Map<String, Object> params = new HashMap<String, Object>();
        params.put("employee", "thomas");
        params.put("reason", "theReason");
        processClient.startProcess(CONTAINER_ID, PROCESS_DEFINITION_ID, params);

        List<TaskSummary> tasks = taskClient.findTasksAssignedAsPotentialOwner(USER, 0, 10);
        taskClient.startTask(CONTAINER_ID, tasks.get(0).getId(), USER);
        // not passing any data = null
        taskClient.completeTask(CONTAINER_ID, tasks.get(0).getId(), USER, null);
    }
}

For a list of Maven dependencies, see example Client Application Intelligent Process Server Dependencies of the Red Hat JBoss BPM Suite Development Guide.

Business Central API Example

To migrate using the Business Central API, see the following example:

import java.net.MalformedURLException;
import java.net.URL;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import org.kie.api.runtime.KieSession;
import org.kie.api.task.TaskService;
import org.kie.api.task.model.TaskSummary;
import org.kie.api.runtime.manager.RuntimeEngine;
import org.kie.remote.client.api.RemoteRuntimeEngineFactory;

 public class Main {

	public static void main(String[] args) throws MalformedURLException {

		/*
		 * Set the parameters according to your installation
		 */

		String APP_URL = "http://localhost:8080/business-central/";

		URL url = new URL(APP_URL);
		String USER = "anton";
		String PASSWORD = "password1!";

    RuntimeEngine engine = RemoteRuntimeEngineFactory
                    .newRestBuilder()
                    .addUrl(url)
                    .addUserName(USER)
                    .addPassword(PASSWORD)
                    .addDeploymentId("org.redhat.gss:remote-test-project:3.0")
                    .build();

    KieSession kSession = engine.getKieSession();
    TaskService taskService = engine.getTaskService();

		 // start a process instance with parameters
     Map<String, Object> params = new HashMap<String, Object>();
     params.put("employee", "thomas");
     params.put("reason", "theReason");
     kSession.startProcess("com.sample", params);

     List<TaskService> taskSummaryList = taskService.getTasksAssignedAsPotentialOwner("anton","en-UK");
     taskService.claim(taskSummaryList.get(0).getId(), "anton");
     taskService.start(taskSummaryList.get(0).getId(), "anton");
     taskService.complete(taskSummaryList.get(0).getId(), "anton", null); // not passing any data = null
  }
}

For a list of Maven dependencies, see example Client Dependencies of the Red Hat JBoss BPM Suite Development Guide.

As you can see, this example is much more simple and readable than the one for Red Hat JBoss BRMS 5. The RemoteRuntimeEngine gives us direct access to the TaskService/KieSession and AuditLogService API.

However, it is still possible to use your arbitrary Java web client and achieve the same scenario by sending GET/POST requests to the appropriate endpoints.

KnowledgeAgent is a component of Red Hat JBoss BRMS 5 which allows you to obtain Knowledge Bases dynamically as it gets updated. If you correctly configure an instance of KnowledgeAgent and then you try to obtain the KnowledgeBase from the agent, you will be able to receive the latest version of the KnowledgeBase including updated resources - whether it is a freshly built package (*.PKG) in Business Central or BPMN process definition updated via the Eclipse designer tool.

See a working example of how this works in version 5 here: KnowlegeAgent Example.

In Red Hat JBoss BRMS and Red Hat JBoss BPM Suite 6, it is also possible to obtain KieBase (instead of KnowledgeBase) dynamically as it gets updated. However, the migration is not so straightforward, because of a few things:

The component which replaces the KnowledgeAgent in BRMS 6 is called KieScanner, and therefore you need to include kie-ci library on classpath if you want to use it.

See an example of how this works in version 6 here: KieScanner Example.

In version 6, you no longer refer to *.PKG files or specific business resources such as drl, bpmn. Instead you configure your KieScanner with a specific KJAR, which is a Maven artifact including your resources, identified by GAV (Group, Artifact, Version). KieScanner uses the Maven Repository to figure out where to look for these built KJARs. If not specified otherwise, it will look into your local Maven repository (by default stored under ~/.m2/ directory on your filesystem).

A typical scenario will be where you set GAV so it identifies the project created in Business Central. KieScanner is now bound to this project, and once you make changes to this project in Business Central and build the project, its latest build will be stored into the local Maven repository (this is the default). KieScanner scans the local Maven repository and picks up the changes. If you want to configure KieScanner in a way that it scans other repositories besides your local one you can do so by setting a system property: kie.maven.settings.custom which can point to the custom settings.xml (a standard Maven configuration file where you include all repositories which should be taken into consideration).

KieScanner invokes Maven under the hood for artifact lookup by following known Maven conventions and rules. For example:

A KCS article which discuss various scenarios and configurations is available at https://access.redhat.com/solutions/710763.

The default underlying database in Red Hat JBoss BPM Suite is an instance of H2. This is fine for most test systems, but production systems are generally based around MySQL, PostgreSQL, Oracle, or others databases. This section lists some of the tips and tricks related to databases when migrating from BRMS 5 to Red Hat JBoss BPM Suite 6.x.

Include hbm.xml for PostgreSQL

If the underlying database on which the migration is being performed is PostgreSQL, you will need to include an additional configuration file, called hbm.xml inside the META-INF directory, next to persistence.xml, with the following contents:

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
    "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
    "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
  <typedef name="materialized_clob" class="org.hibernate.type.TextType" />
</hibernate-mapping>

This file instructs Hibernate to use TextType for materialized CLOBS and solves an issue where Hibernate incorrectly tries to interpret the type of a parameter as Long when it should be String based.

Avoid ID constraint violations in PostgresSQL and Oracle

NodeInstanceLog in BRMS 5.2.x does not have a sequence generator associated with it and was added to have more consistent behavior with multiple databases. Since not all databases initialize the id sequence correctly on migration it is necessary to update the NODE_INST_LOG_ID_SEQ id manually. The two databases that are affected are: PostgreSQL and Oracle.

This tool updates an existing Red Hat JBoss BPM Suite or Red Hat JBoss BRMS installation version 6.3.0 through 6.3.2 to version 6.3.3. The update is distributed in a ZIP file that includes .sh and .bat scripts that automatically apply the updates.

The upgrade tool upgrades an existing Red Hat JBoss BPM Suite or Red Hat JBoss BRMS installation version 6.3.3 to version 6.4.0. The upgrade is distributed in a ZIP file that includes .sh and .bat scripts that automatically apply the upgrade.

This tool updates an existing Red Hat JBoss BPM Suite or Red Hat JBoss BRMS installation version 6.4.0 through 6.4.3 to version 6.4.6. The update is distributed in a ZIP file that includes .sh and .bat scripts that automatically apply the updates.

The upgrade and update tools do not update customized configuration files. The tools look for changes in the local configuration files and if no changes are found, the tools replace the local configuration files with the latest versions. However, if the tools find that a configuration file has been changed, they do not replace that file, but add the updated file to the folder with the extension .new. For example, you have modified the standalone.xml configuration file in your local installation. The upgrade tool sees that it has been changed, so it does not overwrite the file, but adds the standalone.xml.new file to the folder where your standalone.xml file is located. You now have your standalone.xml file and a file named standalone.xml.new.

In addition, the tools append any configuration files in your existing installation that do not have corresponding files in the new installation with the .remove extension, for example standalone.xml.remove.

The following distribution types are supported with Red Hat JBoss BRMS and Red Hat JBoss BPM Suite 6.4:

This section describes changes to client application APIs. Review the changes to the APIs listed in this section if your applications use these APIs.

The org.drools.core.command.runtime.rule.ModifyCommand API is no longer backward compatible in case you create the XML form manually and the Drools engine is using JAXB for unmarshalling. This problem does not occur when the Drools engine uses XStream for unmarshalling. Because the FactHandle object is marshalled differently into the XML, you need to modify the content of the <modify> element in your XML accordingly.

For example:

<modify ...>
  ...
  <fact-handle>0:1:1134443700:1:1:DEFAULT:NON_TRAIT:null</fact-handle>
  ...
</modify>

Needs to be transformed, for example:

<modify ...>
  ...
  <fact-handle external-form="0:1:1134443700:1:1:DEFAULT:NON_TRAIT:null">
    <id>1</id>
    <identityHashCode>1134443700</identityHashCode>
    <objectHashCode>1</objectHashCode>
    <recency>1</recency>
    <entryPointId>DEFAULT</entryPointId>
    <traitType>NON_TRAIT</traitType>
  </fact-handle>
  ...
</modify>

It is recommended to use a marshaller. In such case, no changes are necessary.

org.jbpm.rule.task.waitstate

When set to false, a business rule task automatically fires all rules instead of waiting to be triggered from the process event listener or an outside call. This behavior prevents errors during heavy multithreaded usage, however if org.jbpm.rule.task.waitstate is set to false, the business task is no longer a safe point.

For information about safe points, see the Red Hat JBoss BPM Suite Administration and Configuration Guide.

There are certain measures you need to take when migrating to Red Hat JBoss BRMS 6.3 or Red Hat JBoss BPM Suite 6.3, depending on what version you are migrating from:

API Calls

API Endpoints

If you are running Red Hat JBoss BPM Suite 6.1.X or 6.2.X, you can use the Red Hat JBoss BPM Suite upgrade tool to upgrade to Red Hat JBoss BPM Suite 6.3. To do so, see the section Upgrading to Latest Minor Release in the Red Hat JBoss BPM Suite Install Guide for instructions.

In case you wish to upgrade Red Hat JBoss BPM Suite 6.0.X, you must first upgrade to version 6.2 as described in Section 3.5.2, “Migrating Business Central Project, Repository, and Artifacts from 6.0.X to 6.2”, and use the upgrade tool on the upgraded version.

The Red Hat JBoss BPM Suite upgrade tool upgrades only the distribution files from version 6.2.X or version 6.1.X to version 6.3; you must perform the database upgrade manually. See Section 3.2.4, “Upgrading the Database from 6.X to 6.3”.

The recommended method of upgrading Red Hat JBoss BPM Suite 6.X Git projects (.niogit folder) and Maven local dependencies (bin/repositories) manually is to copy over these directories to the new installation. This process will copy over all projects and artifacts.

Regardless of whether you chose to upgrade the Red Hat JBoss BPM Suite distribution files manually (according to Section 3.2.3, “Migrating Business Central Project, Repository, and Artifacts from 6.X to 6.3 Manually”), or using the upgrade tool (Section 3.2.2, “Migrating from 6.X to 6.3 Using the Upgrade Tool”), you must update the database separately by following instructions in Section 3.6, “Database Migration for 6.x Instances”.

If you are migrating from Red Hat JBoss BPM Suite 6.2 to a higher version, the Intelligent Process Server templates are automatically migrated. The controller configuration resides in the system GIT repository and is migrated automatically. However, if you are migrating from Red Hat JBoss BPM Suite 6.1 to 6.3 or above, the container data is not automatically migrated due to the difference in controller data structure in version 6.1. To retain the container data, first upgrade to Red Hat JBoss BPM Suite 6.2 and then to Red Hat JBoss BPM Suite 6.3. Optionally, you can recreate the container data in your upgraded version of Red Hat JBoss BPM Suite.

In this section, we will discuss the migration steps that are specific to migrating from Red Hat JBoss BPM Suite 6.1.X to 6.2. While the majority of settings and API have remained the same, the differences are highlighted below.

jBPM Executor (embedded mode)

The jBPM Executor has now been exposed as a public API available in the KIE API. In the event that the jbpm-executor service was in use previously, with embedded environments, it is recommended to now create the jBPM Executor using the API.

Deprecated methods

The TaskSummary.getPotentialOwners() is now deprecated and slated for removal.

Update IDs from primitive types

Many IDs were changed from the primitive long to the Object Long. While Java can perform auto-casting of these primitive types, it is recommended to update any uses of the following methods to avoid potential issues:

org.kie.api.task.model.Content.getId();
org.kie.api.task.model.TaskData.getOutputContentId();
org.kie.api.task.TaskService.addComment();

The recommended method of upgrading the Red Hat JBoss BPM Suite 6.1.X Git projects (.niogit folder) and Maven local dependencies (bin/repositories is to copy over these directories to the new installation. This process will copy over all projects and artifacts.

Ensure the database has been upgraded as documented in Section 3.6, “Database Migration for 6.x Instances”.

In this section, we will discuss the migration steps that are specific to migrating from Red Hat JBoss BPM Suite 6.0.X to 6.1.

Remove Old API

As noted in Section 2.2.3, “API and Backwards Compatibility”, 6.1 is not backwards compatible with the 5.X API, while 6.0.X was. Therefore, when migrating from 6.0.X to 6.1 version, you will need to remove all references to the old API.

Modify Your (Custom) persistence.xml

There have been several changes in the classes present in the persistence.xml file. If you have been using a custom file for persistence, then you need to be aware of these changes and implement them:

Migrating Classes

6.1 has migrated some API classes to the Services API (and access to those classes has been removed). If you were using these APIs because no alternative was available earlier, migrate to these new classes:

old --> new
org.kie.internal.deployment.DeployedUnit; --> org.jbpm.services.api.model.DeployedUnit;
org.kie.internal.deployment.DeploymentService; -->  org.jbpm.services.api.DeploymentService;
org.kie.internal.deployment.DeploymentUnit; --> org.jbpm.services.api.model.DeploymentUnit;
org.jbpm.kie.services.api.IdentityProvider; --> org.kie.internal.identity.IdentityProvider;

Make Changes to Module Ids in Your POMs

The following ids have changed:

old --> new
kie-services-jaxb --> kie-remote-jaxb
kie-services-client --> kie-remote-client
kie-services-remote --> kie-remote-services

Review JMS Port Changes

In 6.1, 4447 is the JNDI port to discover JMS ConnectionFactory connection and to get queues. Port 5445 is used by default for unsecured JMS communication. Port 5446 is used by default for SSL secured JMS communication.

In 6.0.X, only port 4447 was necessary to get the JMS ConnectionFactory. This factory provided JMS queues and no other port setting was necessary.

Verify Location of Deployment Units

In 6.1, deployment units are located inside the database. In 6.0, these were stored in the Git repository. If you want to continue storing your deployment units within the Git repo, you must use the system property org.kie.git.deployments.enabled and set it to true.

This change is backward compatible. The first time a deployment is run on a new setup it will read up from system.git and deploy into runtime (in database storage). At the same time it will remove it from system Git to clean it up.

Modify Remote Class API Code

Between 6.0.X and 6.1, the Remote Class API has changed considerably. For example, in 6.0.X, you would use the following code for creating a JMS based runtime engine:

import org.kie.services.client.api.command.RemoteRuntimeEngine;
...
RemoteJmsRuntimeEngineBuilder rjmsreBuilder = RemoteJmsRuntimeEngineFactory.newBuilder().addJbossServerHostName(host).addHostName(host).addUserName(username).addPassword(password).addTimeout(timeout).addDeploymentId(deploymentId).addExtraJaxbClasses(classes);

if( useSsl ) {
  rjmsreBuilder.addKeystoreLocation("client0.keystore.jks").addKeystorePassword(storePassword).addTruststorePassword(storePassword).useKeystoreAsTruststore().addJmsConnectorPort(sslPort);
  } else {
    rjmsreBuilder.useSsl(false).addJmsConnectorPort(port);
  }

RemoteRuntimeEngine remoteRuntimeEngine = rjmsreBuilder.build();

or the following code for creating a REST based runtime engine:

remoteRuntimeEngine = RemoteRestRuntimeEngineFactory.newBuilder().addUrl(url).addUserName(username).addPassword(password).addDeploymentId(deploymentId).addExtraJaxbClasses(classes).build();

This code should be modified as the Remote Class API defines new generalized interface for remote runtime engine: org.kie.api.runtime.manager.RuntimeEngine. To create the runtime engines in 6.1, use the following code (JMS):

// for JMS
import org.kie.api.runtime.manager.RuntimeEngine;
...

RemoteJmsRuntimeEngineBuilder rjmsreBuilder = RemoteRuntimeEngineFactory.newJmsBuilder().addJbossServerHostName(host).addHostName(host).addUserName(username).addPassword(password).addTimeout(timeout).addDeploymentId(deploymentId).addExtraJaxbClasses(classes);

// 5446 is the default secured jms port, 5445 the default unsecured jms port
if ( port == 5446 ) {
  rjmsreBuilder.addKeystoreLocation("client0.keystore.jks").addKeystorePassword(storePassword).addTruststorePassword(storePassword).useKeystoreAsTruststore().addJmsConnectorPort(port);

  sslStatus = "enabled";
} else if (port == 5445) {
  rjmsreBuilder
    .useSsl(false)
    .disableTaskSecurity()
    .addJmsConnectorPort(port);
  sslStatus = "disabled";
  } else {
    throw new IllegalArgumentException("Unsupported jms port, valid ones are secured 5446 and unsecured 5445.");
  }

  RuntimeEngine remoteRuntimeEngine = rjmsreBuilder.build();

and the following code for REST:

remoteRuntimeEngine = remoteRuntimeEngineFactory.newRestBuilder().addUrl(url).addUserName(username).addPassword(password).addDeploymentId(deploymentId).addExtraJaxbClasses(classes).build();

Rename the AuditLogService Class

If you were using the AuditLogService in 6.0.X branch, migrate that to the renamed class: AuditService. Method names have changed accordingly: remoteRuntimeEngine.getAuditLogService() should be changed to remoteRuntimeEngine.getAuditService().

Use the following procedure to move your existing Red Hat JBoss BPM Suite 6.0.X Git projects (.niogit folder) and Maven local dependencies (bin/repositories) to a new Red Hat JBoss BPM Suite 6.1 installation.

Note, the example commands used in the following procedures are based on migrating from Red Hat JBoss BPM Suite 6.0.3 to 6.1.

Migrating a Repository

The following procedure demonstrates how to migrate a selected Red Hat JBoss BPM Suite 6.0.X repository to Red Hat JBoss BPM Suite 6.1.0 installation.

For more information about cloning repositories, see the Red Hat JBoss BPM Suite Administration and Configuration Guide.

Maven artifacts can be migrated using the GUI.

Alternatively, the following procedure demonstrates how to migrate selected Maven artifact from Red Hat JBoss BPM Suite 6.0.X Artifact Repository to a Red Hat JBoss BPM Suite 6.1.0 Artifact Repository, and assumes that the two Artifact Repositories are located on the same physical system.

$ ./standalone.sh -Dorg.uberfire.nio.git.dir=/path/to/6.0.3/.niogit

Ensure that the database has been upgraded as documented in Section 3.6, “Database Migration for 6.x Instances”.

To migrate client applications from Red Hat JBoss BPM Suite 6.0.X to 6.2 the applications must incorporate all of the changes mentioned in both Section 3.4.1, “Migrating Client Application APIs from 6.0.X to 6.1” and Section 3.3.1, “Migrating Client Application APIs from 6.1.X to 6.2”.

Use the following procedure to move your existing Red Hat JBoss BPM Suite 6.0.X Git projects (.niogit folder) and Maven local dependencies (bin/repositories) to a new Red Hat JBoss BPM Suite 6.2 installation.

Note that the example commands used in the following procedures are based on migrating from Red Hat JBoss BPM Suite 6.0.3 to 6.2.

For more information about cloning repositories, see the Red Hat JBoss BPM Suite Administration and Configuration Guide.

Maven artifacts can be migrated using the GUI.

Alternatively, following procedure demonstrates how to migrate selected Maven artifact from Red Hat JBoss BPM Suite 6.0.X Artifact Repository to a Red Hat JBoss BPM Suite 6.2.0 Artifact Repository, and assumes that the two Artifact Repositories are located on the same physical system.

$ ./standalone.sh -Dorg.uberfire.nio.git.dir=/path/to/6.0.3/.niogit

Ensure that the database has been upgraded as documented in Section 3.6, “Database Migration for 6.x Instances”.