Unify 4.8


Jump to: navigation, search


Release Notes

North Plains Unify 4.8

Copyright © 2015 North Plains Systems Holdings, L.P.

Published: 30 January, 2015

1. Overview

1.1. Introduction

This document describes the new features, improvements, and bug fixes implemented in version 4.8 (added since the last release


We recommend that you read and review the entire contents of this document before proceeding with any installation or upgrade of this product.

2. System Requirements

2.1. Supported Operating Systems

North Plains Unify will run on any Oracle Java SE 8 supported operating system, except Windows. Windows support will be added in Unify

2.2. Supported Databases

North Plains Unify works with the following databases, however, Unify is neither packaged nor shipped with any particular database:

  • Oracle (version 12 upwards)
  • MySQL (version 5 upwards using InnoDB engine only)*
  • PostgreSQL (version 9 upwards)

Note that Microsoft SQL server is not supported in Unify 4.8. It will be added back in

* If you wish to use MySQL you will need to download and install Connector/J JDBC driver from the MySQL website; for licensing reasons it cannot be included in the Unify installer package.

2.3. Java Development Kit (JDK)

North Plains Unify requires Oracle Java SE 8 JDK. North Plains recommends using the latest Update of Oracle Java version 8 to run Unify. Unify is neither packaged nor shipped with any particular JDK.

2.4. Tomcat

North Plains Unify 4.8 includes Apache Tomcat 7.0.56. Other versions are not supported.

3. New and improved features in this version

3.1. Deployment module

The composite components that collectively define an instance of Unify (Sites, Templates, Pages, Content Stores, User Realms*, Permissions, etc. ) can now be exported as a single entity. The configurations that determine a client instance can be quickly and easily moved between different instances without the risk of human error. Example uses of this new feature include the moving of development changes between development, test, and production servers, without deploying, changing, or impacting the existing content in any way.

* User Realms, their configuration settings, and Groups are handled, but not actual Users or their Profile Property data.

Additionally, you can now easily import key aspect of an instance's configuration, for example, pages, import configurations, etc.

This will be be of particular benefit to On Brand customers for whom upgrades will become far easier.

To make this more valuable, Unify resources can now be referenced by name rather than ID, making them instance agnostic, and simplifying the process of moving code between servers.

3.2. Development mode

You can now directly develop within Unify without needing to use the backend interface. Local modifications to files are automatically updated by Unify. This change means that you can now use a Version Control System (VCS) of your choice and manage your code directly from within it avoid the need to cut and paste code into the Unify admin interface.

3.3. User and Group REST services

REST services have been extended to include the management of Users and Groups, aiding integration with third parties and increasing the scope to use modern JavaScript frame works such as AngularJS.

3.3.1. User RESTful services (UNF-8067)

This feature exposes the ability to run all the operations with the users in the system using RESTful API. In particular, this allows to:

  • Get information about a single user
  • List users by query
  • Create user
  • Update user
  • Activate user
  • Deactivate user
  • Lock user
  • Unlock user
  • Delete user
  • Reset user's password

3.3.2. User Group RESTful services (UNF-8068)

This feature exposes the ability to run all the operations with the user groups in the system using RESTful API. In particular, this allows to:

  • Get information about a single or multiple user groups
  • Create user group
  • Update user group
  • Delete user group
  • Add user(s) to a group
  • Remove user(s) from a group

3.4. Performance Improvements

This sections details the performance improvements made to Unify in this release.

3.4.1. Indexing improvements

Latest version of Unify contains a number of content indexing improvements, in particular:

  • Underlying libraries (Lucene and Solr) upgraded to version 4
  • Unify now uses Near Real Time indexing which not only greatly reduces the time it takes for changes to appear but also minimises the I/O and query latency.
  • Indexing is now using a shared thread pool instead of thread-per-collection model (for both local and Enterprise search) which allows much quicker processing of item changes
  • For broken indexes it is now possible to quickly find the missing entries and reindex missing items instead of reindexing the entire store
  • When reindexing it is also possible to specify the order so that items having last modified date would be processed first (or last). Can also be ordered by item creation date. All these options are also possible for both local and Enterprise search.

3.4.2. Item content/metadata improvements (UNF-7590)

Reading or writing item attributes (either content or metadata) is now much quicker. In certain situations the complexity has been improved from O(n2) to O(1), leading to major gains in performance and latency.

3.5. Security Improvements

Allow / restrict has been added to the AJAX gateway allowing these to be more tightly secured.

HTTP basic Auth has been added for REST requests.

3.6. Removed or deprecated features

3.6.1. Item Edit Portlet

The old Item Edit Portlet has been removed from the list of portlets that can be added to a page. Old portlets will still be present on pages and will continue to work. However new features will not be added to this portlet and it will not be supported by any new functionality going forward (including the deployment module). The more fully featured Item - Edit using Template portlet should be used instead (or alternatively the Item RESTful Services).

3.6.2. Multivalued attributes

Item attributes had an ability to contain multiple values. This was never implemented and supported properly across the system and this feature has been completely removed in this version. Attribute can now either be absent or present but there can be no multiple values set for any given attribute.

This also means there are only two cardinality options available for both sections and attributes: optional or mandatory.

API backwards compatibility changes:

  • vyre.content.items.Section and vyre.content.items.SectionList classes have been removed
  • vyre.content.items.AttributeList class has been removed. If you need to get the attribute value of an item, use the following:
    Item item = ....;
    // or
    item.getContent().getAttributeValue(attributeDefinitionId, Date.class);
    // also supported are Integer, Long, Double, Boolean and String classes
    // same applies for item.getMetadata().getAttributeValue

3.6.3. XML namespaces

XML namespaces are no longer supported.

4. Migration guide for 3rd party portlets

4.1. Abstract

This document provides the guidelines for migration of 3rd party portlets, with relation to XSL changes in Unify (see https://tracker.northplains.com/browse/UNF-7636).

4.2. Motivation

Unify has migrated XSL entities into Publishing Resource entities for better maintainability and code reuse. This has also allowed creating folders of unlimited level (which was not possible with old XSLs) and other improvements. Unfortunately, this meant that not only XSL ids have changed, but also the related API as the old XSL entities ceased to exist. As usual, with the new release Unify will provide all necessary migration scripts for Unify code, but for any 3rd party code this will have to be done separately, on a case-by-case basis.

4.3. API changes

Unify provides certain API layers; the one exposed to the 3rd party is what we call the worker layer. This layer is expected to contain all necessary methods for operating with certain entities (in this case, XSLs). For XSLs, the relevant worker is vyre.publishing.resources.worker.XslWorker. In order to obtain this worker, you can use Spring or JSR 330 injection annotations. Alternatively, you can get an instance by using BeanFactory:

XslWorker xslWorker = BeanFactory.getInstance().getBean(XslWorker.class);

For every load (find, etc.) operation, this worker will return SourcePublishingResource and/or SourcePublishingResourceBase instances. These correspond to Xsl and XslBase from the previous Unify versions.

4.4. Migration paths

As all XSLs will be migrated to SourcePublishingResources, this will change their IDs and existing portlets will stop working as their configuration end up pointing to the ID which no longer exists. For this reason, all Unify and 3rd party portlets will have to migrate their configurations to use the new XSL id. In order to know which XSL id has migrated to which SourcePublishingResource id, you will have to check the vyre.log for the following:

          {date} {time} [{thread}] DEBUG vyre.publishing.upgrades.v48.FinalizeXslUpgrade - XSL ID={old_id} has been migrated to Publishing Resource ID={new_id}

4.5. Manual option

If the number of portlets is not large, it may be viable to migrate all portlets manually by going to their edit mode and changing the relevant preference to use the new XSL.

4.6. Automated option

With this option, Unify will convert existing portlet preferences automatically, however, you will have to supply the upgrade code. Here are the requirements/steps for it:

  1. Create upgrade class (should extend vyre.core.upgrades.AbstractSQLUpgrade) and upgrade XML file (should be placed in $tomcat_home/conf/upgrades). You can use one of the existing ones in done folder as a template, just change the upgradeClassName.
  2. Upgrade class should have protected void execute(Connection dbConnection) method - which is going to be executed during the upgrade run.
  3. You need to know your portlet definition id (e.g. “vyre_portlets.YourPortlet”). This can be retrieved from the database by selecting relevant records from pm_portlet_instances table.
  4. You need to know whether portlet preferences are stored as a single XML blob or as a row-per-preference. To do that, simply select the relevant record from pm_portlet_pref_values where portlet_id and portlet_version correspond to your portlet instances.
    • If the preferences are stored as row-per-preference, you will need one of vyre.portlets.upgrades.v48.PortletMigrationHelper.getSettings(...) methods
    • If the preferences are stored as a single XML blob, you will need to use vyre.portlets.upgrades.v48.PortletMigrationHelper.getLegacySettings(...) method.
  5. You need to know the preference name for your XSL. Most often it is xslId but your mileage may vary. Preference name can be retrieved by querying pm_portlet_pref_names table or looking at the XML blob contents.
  6. The code to upgrade the portlet should be quite simple and similar to
    List<PortletMigrationHelper.Settings> settings =
    getSettings(dbConnection, "vyre_portlets.YourPortlet", "xslId");
    updateSettings(dbConnection, log, settings, "xslId");

The above case is for when settings are stored as a row-per-setting model. For XML blob, you would need to use getLegacySettings(...) and updateLegacySettings(...).
For more information, refer to PortletMigrationHelper javadoc or contact North Plains support.

5. Issues resolved

The following chapters are a reference to issues completed in version 4.8 along with their respective issue number in the North Plains issue tracking systemhttps://tracker.northplains.com.

5.1. New features

5.2. Improvements

5.3. Bugs resolved

Personal tools