Upgrading to Later Versions

If you are upgrading to a later release of Infinity Process Platform from an earlier release, there are a few things you have to take in account. The following sections document the changes required for specific issues.

For general upgrading, refer to the following topics:

Refer to the following topics if you are upgrading from versions earlier than:

Note to take in account that issues introduced with versions later than your current version that you like to upgrade, but earlier than the latest version might also concern your upgrade.

For details on how to upgrade a Infinity Process Platform version, refer to chapter Upgrading and Downgrading Installed Infinity Process Platform Features in the Installation Guide.

For known issues while upgrading, please refer to the section Upgrade Issues in the Troubleshooting chapter.

Runtime Upgrade

To upgrade the audit trail from a previous Infinity Process Platform version, use the following sysconsole command:

sysconsole upgraderuntime

with the following arguments:

For detailed information on the sysconsole command, refer to chapter The Sysconsole Command of the Operation Guide.

Refer to the release notes of the current Infinity Process Platform version ( Release Notes 9.2.0 ) for details on runtime upgrades like schema changes that will be performed with this command on earlier versions.

Note
To avoid performance issues, please make sure that all your indexes and statistics are up-to-date before starting an upgrade runtime job.

General Model Upgrade

To perform an upgrade of an existing process model you have to distinguish between models older than Infinity Process Platform version 3.0 and later versions. Eclipse is not able to read process model versions older than 3.0. In case you use a model with a version earlier than 3.0, it is recommended to use the sysconsole command to upgrade the model.

Upgrading with the Sysconsole Command Tool

Please ask your administrator to perform the upgrade or use the sysconsole command option upgrademodel to upgrade to a newer Infinity Process Platform version:

sysconsole upgrademodel -file <file> -source <source> -target <target>

Whereby:

For more information on using the sysconsole command please refer to the chapter The Sysconsole Command in the Operation Guide.

Upgrading a Model in the Eclipse Modeler

In case you import a model in Eclipse with an earlier Infinity Process Platform version than you use, you will be prompted and asked if you want to upgrade to the later version:

Upgrade Model Dialog

In case you select No and the version is older than 4.7.0, a warning appears to indicate that this model version is unsupported:

Upgrade Model Warning
Figure: Upgrade Model Warning

You can select Upgrade now to perform the upgrade then and open the diagram of the model. In case you choose Close editor, the model is loaded, but the diagram cannot be edited.

Upgrading a Model in the Portal Modeling Perspective

In case you import a model in the Portal Modeling Perspective with an earlier Infinity Process Platform version than you use, a notification appears above the model tree indicating that one or more models are out of date:

Required upgrade notification
Figure: Required upgrade notification

All models which require an update are indicated via an Upgrade icon. To upgrade all models to the current version, click the Upgrade all Models icon Upgrade in the model tree toolbar.

Click button to upgrade all models
Figure: Click button to upgrade all models

Upgrading Process Manager Facets

Currently there is no automated facility for upgrading the libraries contained in existing Dynamic Web projects with Infinity Process Platform facets to the most recent Infinity Process Platform version. In that case you have to upgrade the Process Manager facets manually as described in detail in the section Upgrading Process Manager Facets of the chapter Creating a Dynamic Web Project in Eclipse .

Upgrading from Versions earlier than 9.2

If you upgrade from versions earlier than 9.2, consider the following issues:

Schema Changes in 9.2

Schema changes have been performed in release 9.2. In order to account for schema changes, performing a runtime upgrade will be necessary to operate against audit trails created with earlier versions. For details on these schema changes, please refer to section Schema Changes of our Release Notes 9.2.

GroupId and ArtifactId Changes in Templating Artifacts

In version 9.2 groupId and artifactId of the Camel Templating artifacts have been changed. Apply these changes to your environment in case you upgrade from a version earlier than 9.2. Replace the groupId and artifactId names in your POM files with the new groupId and artifactId accordingly.

The following table provides an overview on the groupId and artifactId changes for the particular projects:

Project Old GroupId Old ArtifactId New GroupId New ArtifactId
json-utils com.infinity.integration json-utils org.eclipse.stardust.engine.camel stardust-json-utils
camel-itext-convertor com.infinity.integration camel-itext-convertor org.eclipse.stardust.engine.camel stardust-camel-itext-convertor
camel-templating com.infinity.integration camel-templating org.eclipse.stardust.ui.web stardust-web-camel-templating

For example change

  <groupId>com.infinity.integration</groupId>
  <artifactId>camel-itext-convertor</artifactId>

to

  <groupId>org.eclipse.stardust.engine.camel</groupId>
  <artifactId>stardust-camel-itext-convertor</artifactId>

Using a custom Skin in an Upgrade Scenario

If you use a custom skin in your Portal, which was applied in a version earlier than 9.2, you have to re-select it in the Portal Configuration to apply internal changes for default skin preferences.

Please refer to section Selecting the Portal Skin of chapter Configuring general Portal Components in the End User Handbook for details on how to select custom skins.

Using DOCX Files (Templating) with a jackrabbit-jca-2.6.1-infinity01.rar File Configuration

Note that in case you like to use DOCX files, e.g. for templating, and you have a local jackrabbit-jca-2.6.1.rar, which was downloaded via the earlier jackrabbit-jca-2.6.1-infinity01.rar file version, do one of the following:

Model Upgrade required for new Type of predefined Business Date

A model upgrade is required to adjust the primitive data type of the predefined Business Date data to the new type Calendar (was Timestamp).

Please refer to section General Model Upgrade for details on how to upgrade a model with an earlier IPP version.

Upgrading from Versions earlier than 9.0.2

With version 9.0.24.0, document centric access control evaluation is included in a newly created security Jackrabbit repository. In case access control has been set for files individually, access control is now evaluated separately without folder hierarchy inheritance.

If you like to use this feature, but you are using a repository created with an earlier version, you need to configure the AccessControlProvider inside a WorkspaceSecurity tag after the SearchIndex entry for each workspace. In this case add the following workspace security section to the workspace template creation entry in your repository.xml security file:

<Workspace name="${wsp.name}">
   ...
   <!-- Search index and the file system it uses -->
   <SearchIndex class="org.apache.jackrabbit.core.query.lucene.SearchIndex">
      ...
   </SearchIndex>
   ...
   <!-- Workspace Security -->
   <WorkspaceSecurity>
      <!-- Files with ACLs are evaluated separately without Folder hierarchy. -->
      <AccessControlProvider class="org.apache.jackrabbit.core.security.authorization.acl.FileACLProvider" />
   </WorkspaceSecurity>

Note that for existing repositories the same entry needs to be added in the workspace.xml file, which resides in the according repository path, to become effective.

Upgrading from Versions earlier than 9.0

Schema changes have been performed in release 9.0. In order to account for schema changes, performing a runtime upgrade will be necessary to operate against audit trails created with earlier versions. For details on these schema changes, please refer to section Schema Changes of our Release Notes 9.0.

Additionally consider the following issues in case of an upgrade:

Using AuditTrail Databases created with Versions earlier than 9.0 for Tomcat Deployments in RAD

If you use an audit trail database that has been created with an IPP version earlier than 9.0, you have to deselect and select the database from the server configuration page. Republishing the server updates the server.xml file with the new resource definition entry for embedded database usage.

JBoss 6 Archetype has been renamed

With release 9.0, the IPP JBoss 6 archetype has been renamed from ipp-archetype-jb62-eap-ipp-ear to ipp-archetype-jb6-eap-ipp-ear to support JBoss 6.3 EAP and 6.4 EAP. Please consider this change if you upgrade your Maven project from an IPP version older than 9.0.

Upgrading from Versions earlier than 8.2.3

If you upgrade from versions earlier than 8.2.3, consider the following issues:

A runtime upgrade against audit trails created with earlier versions adds the new predefined process instance link type RELATED to the LINK_TYPE in the audit trail. This runtime upgrade job is optional and only required for usage of new link type RELATED.

Note that this upgrade job is a trivial one and can be applied without any risk!

Upgrading from Versions earlier than 8.2

If you upgrade from versions earlier than 8.2, consider the following issues:

Migrate to new Infinity Process Platform Feature Structure and Packaging of Plugins

With Infinity Process Platform version 8.2, the feature structure and packaging of plugins changed. If you like to upgrade from a version earlier than 8.2, you need to perform a migration process. Please refer to chapter Migrating from Versions earlier than 8.2 for details.

Adapt POM Files for removed Maven Module POMs

With the Maven build migration in version 8.2, several Maven module POM files have been removed. Please adjust your projects that might contain references to these accordingly. The following table gives an overview on all removed modules:

Module Referenced Action Required for Migration
base-module Superceded by carnot-base
client-module Superceded by carnot-client
client-spring-module This was only used by the console archetypes, so instead of referencing client-spring-module they are now using the underlying dependencies (carnot-spring, carnot-client and stardust-engine-camel) of the module POM
engine-module Superceded by carnot-engine
stardust-engine-camel-module Superceded by stardust-engine-camel
ws-api-template Superceded by stardust-engine-ws-cxf-web.zip (artifactId: stardust-engine-ws-cxf, classifier: web)
hibernate-module Superceded by carnot-hibernate

Upgrading from Versions earlier than 8.1.2

If you upgrade from versions earlier than 8.1.2, consider the following issues:

JSF Phase Event Broadcasting Behavior changed

To improve performance, a new behavior for JSF Phase event broadcasting is introduced with release 8.1.2 to prevent broadcasting to non-singleton Spring beans. In case you have code relying on the old behavior, set the new Portal configuration switch Carnot.Client.NonSingletonJsfPhaseListeners in your carnot.properties file to true. This will restore the pre-8.1.2 behavior. Note that this will increase the CPU cost of JSF request handling!

Upgrading from Versions earlier than 8.1

If you upgrade from versions earlier than 8.1, consider the following issues:

Exception Handling for embedded Service Factory changed

Exception handling for embedded service factory services changed with version 8.1 to return unwrapped exceptions as with regular API calls. Additionally, raised exceptions now properly honor an existing transaction rollback policy. Note that this change might potentially break existing workarounds you have applied in an earlier version.

Upgrading from Versions earlier than 8.0

If you upgrade from versions earlier than 8.0, consider the following issues:

Changes in IPP Base Components

In version 8.0 the groupIds of IPP base components have been changed. Apply these changes to your environment in case you upgrade from a version earlier than 8.0. Replace the groupId names in your POM files with the new groupId accordingly. Note that only the groupIds have changed, not the artifactIds.

For example change

  <groupId>com.infinity.bpm</groupId>
  <artifactId>ipp-bpm-model-builder</artifactId>

to

  <groupId>org.eclipse.stardust.modeling.model</groupId>
  <artifactId>ipp-bpm-model-builder</artifactId>

The following table provides an overview on the groupId changes for the particular components:

Old groupId New groupId Component
com.sungard.infinity.bpm org.eclipse.stardust.components jcr-vfs
Old groupId New groupId Component
com.infinity.bpm org.eclipse.stardust.engine
2nd-level-cache-hazelcast-module
ant-module
base-module
carnot-base
carnot-client
carnot-engine
carnot-spring
client-module
client-spring-module
ejb21-module
ejb30-module
engine-module
ipp-camel
ipp-camel-module
jax-rs-cxf-module
jax-ws-cxf-module
jcr-api-module
jcr-jackrabbit-module
jcr-jackrabbit-webapp-module
jcr-vfs-module
jms-activemq-module
jms-api-module
jta-api-module
jta-jencks-module
logging-log4j-module
logging-slf4j-log4j-module
qdox-module
spring-module
stardust-engine-ws-cxf
swing-client-module
web-client-module
ws-api-templates
xerces-module
Old groupId New groupId Component
com.infinity.bpm org.eclipse.stardust.examples support-case
Old groupId New groupId Component
com.infinity.bpm org.eclipse.stardust.modeling.core
ipp-bpm-model-validation
ipp-bpm-repository
Old groupId New groupId Component
com.infinity.bpm org.eclipse.stardust.modeling.model
ipp-bpm-model
ipp-bpm-model-builder
Old groupId New groupId Component
com.infinity.bpm org.eclipse.stardust.product stardust-product-nls
Old groupId New groupId Component
com.infinity.bpm org.eclipse.stardust.reporting.app.web
carnot-reporting
carnot-reportrunner
carnot-viewservlets
reporting-web-module
Old groupId New groupId Component
com.infinity.bpm org.eclipse.stardust.ui.common
stardust-common-introspection
stardust-common-introspection-xsd
stardust-ui-form
stardust-ui-form-jsf
Old groupId New groupId Component
com.infinity.bpm org.eclipse.stardust.ui.web
ipp-administration-perspective
ipp-business-control-center
ipp-end-user-doc
ipp-graphics-common
ipp-portal
ipp-portal-api
ipp-portal-common
ipp-views-common
ipp-workflow-perspective
jsf-api-module
jsf-myfaces-module
stardust-rules-manager
stardust-web-modeler
stardust-web-modeler-bpmn2
stardust-web-reporting

In case you do not find a specific component in this table, please check in the artifactory accordingly. Login to the Infinity artifactory (https://infinity.sungard.com/repository) and enter the artifactId in the search field accordingly.

Apache FOP Dependency needs to be excluded in Custom Development

In case you use a custom development and upgrade from an IPP version earlier than 8.0, you face issues caused by dependencies on Apache FOP (Formatting Objects Processor). Adding the following exclusion to your project's pom.xml file resolves the problem:

   <exclusion>
      <artifactId>batik-js</artifactId>
      <groupId>org.apache.xmlgraphics</groupId>
   </exclusion>

Stricter XML Namespace Validation

XML namespaces validation has become stricter since version 8.0. You might face issues if you upgrade from an IPP version earlier than 8.0 and the following points apply:

For example missing namespaces for a child element of an element fails with an XML processing error since IPP versions 8.0. Make sure that your XMLs follow the correct XML namespacing standards.

Note that IPP core APIs and services are not impacted because IPP APIs and services use proper XML namespacing standards.

See the following examples with wrongly or correctly used namespaces:

Solution

When you upgrade IPP, if it is possible to change the client applications (that is embedded / integrated with IPP), revisit the namespacing for the XML documents used in your solution and make sure that you have standard XML namespaces for your schemas.

In case it is not possible to change the client applications or the XML namespaces, then you will have to analyze each case and implement solutions like in the below example scenario, to indicate to the XML processors in the IPP product, of the XML namespaces it has to be aware of while processing your XMLs.

Example solution for an existing SOAP endpoint created with a version earlier than 8.0

There can be many ways a solution may implement services that consume and produce XML. Below is an example - a java-to-wsdl webservice - which a solution implements on top of the IPP platform and a proposed solution for this specific problem.

  1. A simple SOAP endpoint is created with an IPP version earlier than 8.0 using CXF like shown below:
  2. The above service is built and deployed on an IPP version earlier than 8.0.
  3. The Test Webservice is invoked on an IPP version earlier than 8.0 using the SOAP body as shown below:
    <soap:Body>
       <com:testOperation xmlns:com="http://ipp.sungard.com/">
          <testInput>100</testInput>
       </com:testOperation>
    </soap:Body>
  4. If you invoke the same Webservice on an IPP version later or equal 8.0 using the same SOAP body, the following error will be thrown:
    Unmarshalling Error: unexpected element (uri:"http://ipp.sungard.com/", local:"testInput"). Expected elements are <{}testInput>
    But the below SOAP request will work (note: this means that the SOAP clients may need to be changed when upgrading):
    <soap:Body>
       <com:testOperation xmlns:com="http://ipp.sungard.com/">
          <testInput>100</testInput>
       </com:testOperation>
    </soap:Body>

Solution:

On IPP version later or equal 8.0, for Java to WSDL, you have to let the JAXP libraries know explicitly that the XML element form default is qualified to pass on the namespacing to operation arguments and attributes.

You will have to create a package-info.java for every package (data and service packages involved in the SOAP service) like shown below:

@javax.xml.bind.annotation.XmlSchema(namespace="http://ipp.sungard.com",
   attributeFormDefault=javax.xml.bind.annotation.XmlNsForm.QUALIFIED,
   elementFormDefault=javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
   package com.sungard.ipp;

Upgrading from Versions earlier than 7.3

If you upgrade from versions earlier than 7.3, consider the following issues:

Upgrading predefined link types (optional)

A runtime upgrade against audit trails created with earlier versions adds the new predefined process instance link type SPAWN to the audit trail. The SPAWN link type describes the case for just creating a new root process instance from an existing one with optionally copying data. This runtime upgrade job is optional if you are not using the spawn functionality.

Note that this upgrade job is a trivial one and can be applied without any risk!

Upgrading Models with Visual Rules Applications

If an old model contains a Visual Rules application, which is de-supported since version 7.3, a corresponding warning is shown during the deployment.

Upgrading from Versions earlier than 7.2

If you upgrade from versions earlier than 7.2, consider the following issues:

Schema Upgrades in 7.2

A runtime upgrade for versions earlier than 7.2 adds the following columns to your schema:

Upgrading customized Components to HTML5 Shell Usage

In case you are using customized views or perspectives created with Infinity versions earlier than 7.2, you need to perform some changes on your custom code. Please refer to section Upgrading your customized Components to HTML5 Shell Usage of chapter Extending Infinity Portal Components for details.

Necessary Principal Login Deployment Descriptor Changes

You need to adjust your web.xml file in case you use principal login configured with a version earlier than 7.2. Please refer to section Activating Principal Login of chapter Logging in the Infinity Portal in the End User Handbook for details on the required settings in your web.xml.

External Web Applications - Updating JavaScript Source File Reference for Versions earlier than 7.2

In case you are using the JavaScript source file IppProcessPortalClient.js in your external Web application, you need to upgrade it with the new one provided in the ipp-workflow-perspective.jar file of the new Infinity Process Platform installation.

Upgrading from Versions earlier than 7.1.3

If you upgrade from versions earlier than 7.1.3, consider the following issues:

Adjust CXF Spring Application Context File Locations

Since 7.1.3, all Spring context files need to reside in the default location, which is META-INF/spring .

Make sure that all your CXF application contexts reside in META-INF/spring instead of META-INF/spring/cxf , for example adjust the following projects:

Adjust all web.xml descriptors pointing to CXF application contexts, for example:

Upgrading from Versions earlier than 7.1.1

If you upgrade from versions earlier than 7.1.1, consider the following issues:

Upgrading from Versions earlier than 7.1.1 - Updating Derby Jars

In case you upgrade your Infinity Process Platform installation from a version earlier than 7.1.1, you have to do the following:

  1. Remove all derby JARs (derby.jar, deryclient.jar, derbynet.jar) from <tomcat-install-dir>/lib
  2. Create a new Web project and publish it into Tomcat
  3. Now only the latest Derby JARs should be located at <tomcat-install-dir>/lib

Upgrading from Versions earlier than 7.1

Schema changes have been performed in release 7.1. In order to account for schema changes, running a runtime upgrade will be necessary to operate against audit trails created with earlier versions. Refer to Release Notes 7.1 for details on these schema changes.

Additionally, consider the following issue in case you upgrade from versions earlier than 7.1:

Ignoring Exception for missing XPath during Migration from Versions earlier than 7.1

Due to XSD changes in 7.1, you might face a null pointer exception "Operation could not be performed: null" during a runtime upgrade job from a version earlier than 7.1. To avoid this exception, set the property Infinty.RTUpgrade.7_1_0.IgnoreMissingXPath in your carnot.properties file to true. With this property set, the missing XPath issue will be ignored and no exception occurs.

Portal Framework - Attributes not supported in custom Perspectives since Version 7.1

Since version 7.1, the following attributes are not supported anymore in your custom configuration files:

In case you use custom perspectives created with Infinity Process Platform versions earlier than 7.1, you need to remove these attributes from your context definition xml file.

Upgrading from Versions earlier than 7.0

Schema changes have been performed in release 7.0. In order to account for schema changes, running a runtime upgrade will be necessary to operate against audit trails created with earlier versions. Refer to section Schema Changes of the Release Notes 7.0.0 for details on these schema changes.

Additionally consider the following issues, if you upgrade from versions earlier than 7.0:

Old Validator Attributes remain in Model Files

If you upgrade a model created with a version earlier then 7.0, some validator application attributes with an old package structure "ag.carnot.*" remain in the XPDL file. They do not cause issues, but in case you like to avoid confusion you can simply remove them.

No Configuration Variables for Criticality in Models created with Versions earlier than 7.0

Models created with Infinity Process Platform versions earlier than 7.0 do not contain configuration variables needed for criticality calculation in the default formula. These configuration variables are created during model creation with later releases. For details on these configuration variables refer to section Standard JavaScript Formula of chapter Activity Criticality.

Also, if a model created with an earlier version is already deployed and when you try to upgrade, the Predefined model gets deployed automatically. So when using processes started in an earlier version, you can perform spawn, abort and join, abort and start and create case functionalities.

Using Structured Data Types having XOM Conversion

Since Infinity Process Platform version 7.0.0, XOM conversions are not supported anymore. In case you are working with a model using data paths created with an earlier version, a validation warning appears to indicate that the data path is not valid. Please adjust and use another data path in that case. If the model is deployed and the process executed anyway, an exception will be thrown due to unknown conversion.

Working with JSF Activities Converted with Version earlier than 7.0

Perform the following manual changes to XHTML and Bean files:

For more information, please refer to the chapter Converting Manual Activities to JSF Application Activities of the Modeling Guide.

External Web Applications - Updating JavaScript Source File Reference for Versions earlier than 7.0

Note that for each upgrade of Infinity Process Platform Portal earlier than 7.0, you need to copy the IppProcessPortalClient.js from the ipp-workflow-perspective.jar file, keep it in your web application and include it in context. So whenever you upgrade, make sure that you are using newly available IppProcessPortalClient.js and not the old IppProcessPortal.js from the version earlier than 7.0. For more information, please refer to the chapter Using External Web Applications chapter of the System Integration.

Upgrading from Versions earlier than 6.0

Schema changes have been performed in release 6.0. In order to account for schema changes, running a runtime upgrade will be necessary to operate against audit trails created with earlier versions. Refer to Release Notes 6.0.0 for details on these schema changes.

Behavior of Legacy Models since Infinity Process Platform Version 6.0

Infinity Process Platform uses XPDL version 2.1. However, the legacy models that are created using older XPDL versions get loaded and upgraded as XPDL 2.1 model. If you change anything in the model then that change persists the model as XPDL 2.1 model.

Also, note that existing models without references to other models are treated as in earlier Infinity Process Platform versions. However, new versions of the same model or other models can be deployed additionally to an existing audit trail based on the deployment rules.

Behavior of Grants from Models created with Versions earlier than 6.0

In case a model is created with a Infinity Process Platform version earlier than 6.0, grants existing from other model versions than the active model are deleted. In case you face problems due to this behavior, please contact the Infinity Process Platform support team.

Reading Preferences Stored with Versions earlier than 6.0

In Infinity Process Platform versions earlier than 6.0, preferences were stored via Document Management Service. To migrate between the Document Management Service based storage and Database storage, some manual steps are necessary.

To be able to read preferences from the DMS, the server-side configuration property Infinity.Preferences.Store needs to be set to the value DMS_READ_ONLY . It is recommended exporting the preferences to a zip file using the following console command:

preferenceStore -backup -targetFile <targetfile>

For details on this command, refer to section Storing Preferences of chapter Using Console Commands in the Operation Guide.

To switch back to the new default AuditTrail based storage of preferences, now the server-side property needs to be removed or changed to Infinity.Preferences.Store=AuditTrail . The runtime needs to be restarted.

After the restart, the preferences can be loaded from the zip file using the following console command:

preferenceStore -load -sourceFile <sourcefile>

After this step all exported preferences are present in the AuditTrail and the DMS preferences can be removed manually from the DMS if needed.

Upgrading from Versions earlier than 5.2

Models having Administrator Role connected to Organization

Since Infinity Process Platform version 5.2. and later, it is not possible to connect the Administrator role to any organization. In case models with Infinity Process Platform versions older than 5.2 contain such a connection, an error message is diplayed in the Problems view.

New Property Carnot.Configuration.UseDocumentRepository

In case of a migration from a Infinity Process Platform version earlier than 5.2, the property Carnot.Configuration.UseDocumentRepository determines if the configuration data stored in operating system files are migrated into the global space of a repository-based management. This migration will occur on startup of the runtime environment and is transactional. The original files are kept and can be used if the property is changed to false .

Upgrading from Versions earlier than 5.1

Using JSF Managed Beans

Since version 5.1.0 it is possible to open several activities of the same kind at the same time. Using session-scoped managed beans for interactive JSF activities, as common in earlier versions, might thus lead to corrupt process data. Use Spring-based beans declared with a view scope instead. For details refer to chapter Integrating JSF Applications of the System Integration.

Upgrading from Versions earlier than 5.0

Upgrading Web Projects using Process Manager Facets with Versions 5.0.x and earlier

In case you are working with Web projects containing Infinity Process Platform Portal facets created with a release earlier than 5.1., upgrading the Infinity Process Platform Portal facets is not possible. With release 5.1., the Infinity Process Platform Portals were replaced by an ICEFaces based implementation. To upgrade to the new version:

  1. Create a new Web project.
  2. Add the new Infinity Process Platform Portal facets to the new project.
  3. Import your model and source files to the new project.

Upgrading the Jackrabbit Repository from Version 5.0 and earlier

This section provides the migration steps to make a deployment possible with a repository created with Infinity Process Platform versions 5.0 or earlier.

General Procedure

Existing folders and files need to be moved to a new sub-folder /ipp-repository/partitions/<partitionId> since the DocumentManagementService internally works under the new partition specific folders. Only files and folders in the corresponding partition sub-folder are exposed on the DocumentManagementService.

  1. If existing, remove the missing-auth-mapping section from your web.xml jackrabbitJcrWebdavServlet configuration, so the WebDav client does not default to a specified user.
  2. If not existing, add the following Jackrabbit repository servlets to your web.xmlfile:
      <servlet>
       <display-name>Jackrabbit Repository Servlet (Simple Webdav)</display-name>
       <servlet-name>jackrabbitSimpleWebdavServlet</servlet-name>
       <servlet-class>org.apache.jackrabbit.j2ee.SimpleWebdavServlet</servlet-class>
       <init-param>
          <param-name>resource-path-prefix</param-name>
          <param-value>/jackrabbit/repository</param-value>
       </init-param>
          <param-name>missing-auth-mapping</param-name>
       <init-param>
          <param-value>anonymous:anonymous</param-value>
       </init-param>
       <init-param>
          <param-name>resource-config</param-name>
          <param-value>/WEB-INF/jackrabbit/webdav-config.xml</param-value>
       </init-param>
       <load-on-startup>4</load-on-startup>
      </servlet>
    
    <servlet> <display-name>Jackrabbit Repository Servlet (JCR over Webdav)</display-name> <servlet-name>jackrabbitJcrWebdavServlet</servlet-name> <servlet-class>org.apache.jackrabbit.j2ee.JCRWebdavServerServlet</servlet-class> <init-param> <param-name>resource-path-prefix</param-name> <param-value>/jackrabbit/server</param-value> </init-param> <load-on-startup>5</load-on-startup> </servlet>
  3. Use a WebDav client, e.g. Windows WebFolders (Windows XP integrates it in My Network Places) to connect to your deployment with the configured resource-path-prefix e.g.
    http://localhost:8080/ipp/jackrabbit/server/
  4. Enter the username configured as the adminID in your repository.xml, e.g. /ipp/carnot-jackrabbit/WEB-INF/jackrabbit/repository.xml (default is admin).
  5. Enter no password, (the default Jackrabbit login manager does not check for a password).
  6. Finally use the WebDav client to move the existing folder structure to the new /ipp-repository/partitions/<partitionId> folder.
  7. After the procedure, remove the Jackrabbit repository servlets.

repository.xml settings

<Security>
<LoginModule class="...">
<!-- anonymous user name (anonymous is the default value) -->
<param name="anonymousId" value="anonymous"/>
<!-- administrator user id (default value if param is missing is admin) -->
<param name="adminId" value="admin"/>
</LoginModule>
</Security>

Specific Procedure

Path change overview

Old path New path
/processInstances /ipp-repository/partitions/<partitionId>
/process-instances
/Correspondence Templates and Paragraphs /ipp-repository/partitions/<partitionId>
/documents/correspondence-templates
/Personal Documents <userId> /ipp-repository/partitions/<partitionId>/realms/<realmId>/users/<userId>/documents

Process Instances

  1. Login to the new portal and go to the Administration perspective > Document Repository View.
  2. Create the folder process-instances by right-clicking on the folder named Root and selecting Create Subfolder.
  3. Go to WebDav. Move all folders below the /processInstances path, e.g. 2009 and 2011, folder to /ipp-repository/partitions/<partitionId>/process-instances (default naming pattern is a 4 digit year /processInstances/<yyyy>).
  4. The old /processInstances folder can be deleted now.

Correspondence Templates

  1. Login to the new portal and open the My Documents tab found on the Workflow Execution perspective, on the Documents section.
  2. The My Documents and Common Documents sections (containing the correspondence-templates folder) are created in the repository.
  3. Check for existing example templates and remove them if necessary. (Claim Templates, Complaint Templates).
  4. Now move all folders from /Correspondence Templates and Paragraphs to the now existing /ipp-repository/partitions/<partitionId> /documents/correspondence-templates folder using WebDav.
  5. The old /Correspondence Templates and Paragraphs folder can be removed now.

Personal Documents

This section demonstrates with an example how to handle the personal documents parts. The example uses the following settings:

Old Documents stored in:
/Personal Documents motu

New path:
/ipp-repository/partitions/default/realms/carnot/users/motu/documents

Remaining Documents

Other folders or documents located on the old root path / , e.g. folders created via DocumentManagementService API calls, have to be moved to /ipp-repository/partitions/<partitionId> to be accessible by the DocumentManagementService (or the portals which use it).

For example:

/Document.txt WebDav move to:
/ipp-repository/partitions/default/Document.txt

The Document.txt will be accessible by the new Infinity Process Platform version DocumentManagementService with a login on the default partition, by the same call as on the Infinity Process Platform version 5.0 DocumentManagementService:

dms.getDocument("/Document.txt");

Upgrading from Versions earlier than 4.8

Upgrading Model Element IDs

Since release 4.8.0, stricter rules have been introduced for model element IDs. In case you upgrade a model with an earlier version, containing element IDs, which are no longer supported, a dialog opens to offer a replacement of the invalid character. Please refer to the section ID of the chapter Representation of Model Elements for detailed information on this dialog and on supported model element IDs.

Upgrading from Versions earlier than 4.7

Schema changes have been performed in release 4.7. In order to account for schema changes, running a runtime upgrade will be necessary to operate against audit trails created with earlier versions. Refer to Release Notes 4.7.0 for details on these schema changes.

Automatic Upgrade of Transition Conditions

With Infinity Process Platform Release 4.7.0 the new JavaScript transition condition editor was introduced. In case you upgrade a model created with an earlier version, the transition conditions will be updated to the new standard automatically.

Upgrading from Versions earlier than 4.5

Lanes Behavior during a Model Upgrade

During a model upgrade from a Infinity Process Platform version earlier than 4.5, the lanes in a model have to be adapted to the new lane behavior, e.g. having all elements in lanes. In case the model has symbols not residing in lanes, a new lane is created and these symbols will be moved there.

Please note that you have to reposition the symbols in that lane to meet your requirements. All existing lanes will be reordered. In some cases the lanes will overlap each other, enlarging and repositioning the lanes will make them appear again.

Please refer to the chapter Pools and Lanes Usage for detailed information on handling lanes.

Upgrading Descriptor-based Notes

Descriptor-based notes added with a release version 4.5 or earlier will be updated automatically to be stored as process instance properties. The referenced data for these data paths have to be of type String with no access path applied. Otherwise they cannot be converted and an error message appears:

This is no note of type string or big string.

In case you get such an error message, please contact the Infinity Process Platform support team.

Upgrading from Versions earlier than 3.0.1

Since release 7.2, upgrading of the Audit Trail and the Model from versions earlier than 3.0.1 is not supported anymore. If you like to upgrade from a version earlier than 3.0.1, you have to upgrade from that version to version 7.1 and from there to a version 7.2 or later.