Process Dependencies and Case Data Model Versions

A process that references an element in a case data model has an application dependency on the exact version of the referenced case data model. It is important to understand the implications of this exact-match relationship, and to manage those implications when upgrading either a case data model or a dependent process. Not doing so could result in deployment errors or runtime issues.

When you deploy (or generate the DAA for) a process project that references a data element in a Business Data project:

  • The process application has an application dependency on the referenced business data application. This dependency is recorded against the exact version number of the Business Data project that exists when the process application is deployed (or the DAA generated).
  • That version of the case data model must be deployed before you can deploy any process project that references it. Attempting to deploy the process project first will result in a deployment error.
  • Process instances can only access the case data tables and case data specifically defined by the version of the case data model on which they are dependent.

Consequently, TIBCO recommend that you keep version numbers of case data models and dependent process projects in step with each other. Whenever you upgrade a case data model, you should review the impact on all process projects that reference that case data model, and upgrade process projects as required.

The following example illustrates how successive updates to the very simple Customers case data model (described in Case Data Model Versioning) could impact an equally simple process project that uses that case data model, and how a solution designer could manage that impact.

  1. The solution designer creates and deploys the Customers Business Data project.
  2. He creates a process project, Register_Customers, that uses the Customer case class provided in the Customers Business Data project.
  3. He deploys the project, creating the process application com.example.reg.cust. Because it uses the Customer case class, this application has a dependency on the 1.0.0.qualifier version of the com.example.customers-1 business data application.
  4. He runs an instance of the Register_Customers process, which creates a customer object in the BDS_1_CUST_CUSTOMER case data table.

Upgrading the Process Application Following a Minor Upgrade of the Case Data Model

The solution designer subsequently updates the Customers project, adding an optional firstName attribute to the Customer class.

  1. The solution designer deploys the Customers project.
  2. He then updates the Register_Customers process to make use of the new firstName attribute on the Customer case class.
  3. He deploys the process as an upgrade to the com.example.reg.cust application. This version of the application has a dependency on the upgraded version of the com.example.customers-1 business data application.
  4. He runs an instance of the upgraded Register_Customers process, which creates a customer object in the BDS_1_CUST_CUSTOMER case data table (for the customer Gerald Fathom).
  5. Note that existing process instances of the original version of the com.example.reg.cust application continue to run and use the same case data table, but cannot access the FIRSTNAME data values. For example, if a later task in the Register_Customer process returns details of a customer based on search criteria applied to the LASTNAME, the following table shows the different search results that would be returned by each version of the process, even though both versions are using the same search string and accessing the same case data table.
    Search string Register_Customers process version Data returned
    Crestor 1.0.0 Crestor
    1.0.1 Crestor
    Fathom 1.0.0 Fathom
    1.0.1 Gerald Fathom
Note: This scenario is only possible if the Register_Customer process uses the firstName attribute in a way that does not affect the process' service interface. If, for example, the process wanted to use the customer's first name as an input parameter, this would change the service interface and application upgrade would be impossible.

Upgrading the Process Application Following a Minor Upgrade of the Case Data Model that Breaks the Process' Service Interface

  1. The solution designer updates the Register_Customers process to make use of the firstName attribute, using it as an input parameter to the process. However, this changes the process' service interface, which means that the process application cannot be upgraded.
  2. He cancels all in-progress instances of the version 1.0.0 application, then undeploys and deletes the application.
  3. Deleting the process application removes the dependency on the original version of the com.example.customers-1 business data application. As a later version of this application has already been deployed, the BPM runtime now deletes the 1.0.0 version.
  4. Although the 1.0.0 versions of both the process and business data applications have been deleted, the data written by those applications to the BDS_1_CUST_CUSTOMER case data table (the Crestor record) is not deleted.
  5. The solution designer can now deploy the Register_Customers process as a new application.
  6. He then runs an instance of the Register_Customers process, which creates a customer object in the BDS_1_CUST_CUSTOMER case data table (for the customer Gerald Fathom).

Upgrading the Process Application Following a Major Upgrade of the Case Data Model

The solution designer again updates the Customers project, changing the firstName attribute to be a mandatory attribute of the Customer class. This constitutes a destructive change to the model, so the major component of the project Version number must be updated (to 2). Deploying the project again results in the creation of a new application and a new case data table.

  1. The solution designer updates the Register_Customers process to handle the use of the mandatory Customer.firstName attribute.
  2. He then deploys the process as a new application, which has a dependency on the com.example.customers-2 application.
  3. Running an instance of the Register_Customers process creates a customer object in the BDS_2_CUST_CUSTOMER case data table (for the customer Doris Bethel).
Note: The com.example.reg.cust2 application has no access to the data in the BDS_1_CUST_CUSTOMER case data table, and the com.example.reg.cust application similarly has no access to the data in the BDS_2_CUST_CUSTOMER case data table.