Process 16.0

Setup

On premise

• install-windows-16.0.0.exe
• install-linux-x64-16.0.0.run

Changes since Process15.0.0 :

• Data pool, Websites and Documentary space are no longer to choose from
• News, Editorial, Forums, Links, Poll to no by default

Cloud Manager

New type of “Process” tenant.

Configuration

Configurator

Launch by config.bat or config.sh

Changes since Process15.0.0 :

• General : Country code in addition to the language (for locale)
• Report publication : checkbox to activate the deployment of the war for the engine concerned
• Report publication : birt, possible to configure a remote server
• Advanced parameters : web application, development mode, if checked, recompile the jsp each time
• Advanced parameters : web application, redirection URL for the root, defined the URL positioned in the ROOT.war ( served at the root of the server)
• Advanced parameters : port numbers, include a max size parameter for POST requests
• Advanced parameters : port numbers, include a parameter for the https port
• Advanced parameters : port numbers, used to configure the port of the Wildfly management console

Debug

To activate the remote debug, you must set the value DEBUG_MODE* to true and configure a listening port number * DEBUG_PORT_VAR* in the script HOME/scripts/custom/var. For example to enable debug on port 8000 in Windows:

set DEBUG_MODE=true
set DEBUG_PORT_VAR=8000

Advanced parameters: Java in “Manual configuration (file)”

Previously this mode of operation was not clearly defined or documented.

By activating the “Manual configuration (file)” mode, you can now use the files HOME/scripts/custom/custom.conf.bat for Windows and HOME/scripts/custom/custom.conf for Linux.

These files allow you to modify or completely override the JAVA_OPTS variable.

Here is an example on Linux in order to activate Perfino:

JAVA_OPTS="$JAVA_OPTS -Xmx2G -Xms2G -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m "
JAVA_OPTS="$JAVA_OPTS -javaagent:/opt/perfino/perfino.jar=server=server.exemple.com,name=client_name,group=moovapps_process"

Standalone descriptor

From version 16 of Process, the configuration of the application server is done in a single file (_ HOME/wildfly/standalone/configuration/standalone-process.xml_) which replaces the old login-config.xml, jboss files -log4j.xml, vdoc-ds.xml, …

If you have specific configuration needs that are not supported by the configurator, you can create a HOME/wildfly/standalone/configuration/standalone-custom.xml file from the file HOME/wildfly/standalone/configuration/standalone.xml and add your changes to it.

The next generation of the standalone-process.xml file will be made from the standalone-custom.xml file and will take your changes into account.

When generating the standalone-process.xml file, if a configuration is already present in the _ standalone-custom.xml_ file, the conigurator will not modify it.

Login modules

In versions prior to 16, login modules were configured in the login-config.xml file. From version 16, this configuration is done in the standalone …. xml files.

It is possible to add a specific module login using the file _ HOME/wildfly/standalone/configuration/standalone-custom.xml_ and adding his declaration.

Here is an example of configuration of the login module “Specific LoginModule” in the file _ HOME/wildfly/standalone/configuration/standalone-custom.xml_:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<server xmlns="urn:jboss:domain:6.0">
    ...
    <profile>
    ...
    <subsystem xmlns="urn:jboss:domain:security:2.0">
    <security-domains>
    ...
    <security-domain name="VDoc">
    <authentication>
        ...
        <login-module code="com.axemble.security.specproject.loginmodules.SpecificLoginModule" flag="sufficient"
                      name="SpecificLoginModule"/>
    </authentication>
    ...
</server>

The order of declaration of the login modules in the authentication tag defines the order in which these login modules will be executed.

Scripts

Only the scripts present in the scripts/custom sub-directory are intended to be modified on the Process instances in production.

Scripts / start, stop, config et applyconfig

Renaming scripts

Compared to previous versions of Process, the scripts startvdoc, stopvdoc and configvdoc have been renamed to start, stop and config respectively in both Microsoft version (.bat) and Linux version (.sh).

Description of scripts

Each of the following scripts is available in a Microsoft version (.bat) as well as a Linux version (.sh).

• start : the start script is used to start the Process instance. It uses the script HOME/scripts/custom/var in order to load its configuration.
• stop : the str script is used to stop the Process instance in operation. It uses the script HOME/scripts/custom/var in order to load its configuration.
• config : the config script is used to launch the configurator in a graphical interface.
• applyconfig : the applyconfig script is used to apply the configuration (config.properties, fixes, apps and custom).

Windows specific

The scripts start.bat, stop.bat and applyconfig.bat accept the server parameter which allows them to be executed in the current console without creating a new one.

Scripts / installservice and uninstallservice

Previously

In version 15.5 and lower, the installation (and uninstallation) of Process as a service was done by scripts:

• installservice.bat
• uninstallservice.bat

In version 16.0

The operations on Process as a service are done with the script service.bat (under windows) or service.sh (under linux). When this script is launched, it offers the following operations:

• install : Installs the service under the name SERVICE_NAME
• uninstall : Uninstall the service named SERVICE_NAME
• start : Starts the service named SERVICE_NAME
• stop : Stop the service named SERVICE_NAME
• restart : Restart the service named SERVICE_NAME

The default service name, SERVICE_NAME, is Moovapps Process. (This name is defined in HOME/scripts/custom/var)

Scripts / var

The HOME/scripts/custom/var script is used by other scripts to load their configuration.

Configuring the debug port

As seen in the Configuration / Debug section, the debug port is configured in the script HOME/scripts/custom/var .

Configuration of listening addresses

By default, the Process instance listens on all of its IP addresses. It is possible to modify this configuration by modifying the variable BIND_ADDRESS in the script HOME/scripts/custom/var.

If we take the example of a server with two network interfaces using the two IP addresses 192.168.50.10 and 172.16.1.1, we can only run the Process instance on the first IP: set BIND_ADDRESS=192.168.50.10

In-service launch configuration

You can modify the variables:

• SERVICE_NAME : Name of the service
• SERVICE_DISPLAY : Label of the service
• SERVICE_DESC : Description of the service

Windows example

SET SERVICE_NAME=MoovappsProcessB
SET SERVICE_DISPLAY="Moovapps process seconde instance"
SET SERVICE_DESC="Moovapps process service seconde instance"

On Linux the following two variables are required:

• SERVICE_USER : User owner of the file and launcher of the service
• SERVICE_GROUP : Group owner of the file

Linux example

export SERVICE_NAME=MoovappsProcessB
export SERVICE_DISPLAY="Moovapps process seconde instance"
export SERVICE_DESC="Moovapps process service seconde instance"
export SERVICE_GROUP=moovappsAdmins
export SERVICE_USER=moovapps

Definition of the JVM used

Here is the default behavior for setting the location of the JDK:

1. We see if a jdk folder is present in the installation folder of the Process instance.
2. Otherwise, we look for a variable JAVA_HOME and if so we use it.
3. Otherwise, we try to use the java executable, considering that it is in the path. In this case, an alert message is displayed.

Migration

Migration / On premise

• Check the prerequisites
• The migration is done from a stopped 15.5 instance.
• Make a backup of databases and contentstore, apps and custom.
• Identify the specific configuration (login-module, logs …).
• Identify the apps that are no longer compatible, and recover a compatible version 16.0.
• Install instance 16.0 from setup exe or run.
• Configure instance 16.0 indicating the bases of instance 15.5.
• Copy the contentstore to the contentstore directory of instance 16.0.
• Copy the custom into the custom directory of instance 16.0.
• Copy compatible apps to the apps directory of instance 16.0.
• Make an applyconfig. * Start the instance.
• Check that the start is made without error.

Migration / points of attention

Adding rights to use the schema in Oracle databases

Reason: the vdoc-ds datasource, corresponding to the Proces database, is an XA datasource. To support XA transactions rights are needed for the schema user. Let MY_DATABASE_16_0_0 be the database schema, run:

GRANT SELECT ON sys.dba_pending_transactions TO MY_DATABASE_16_0_0;
GRANT SELECT ON sys.pending_trans$ TO MY_DATABASE_16_0_0;
GRANT SELECT ON sys.dba_2pc_pending TO MY_DATABASE_16_0_0;
GRANT EXECUTE ON sys.dbms_xa TO MY_DATABASE_16_0_0;

Limit writes to the WAR (and to the disk)

Reason: good EJB practice, which you can find here. Currently Process 16.0 runs on a single server. If in the future it became necessary to allow it to be deployed in a distributed environment, writes would be a difficult migration point.

Use ManagedThreadFactory to start threads

Reason for change: With the version upgrade of the application server, if a thread is created by hand, it does not have access to the j2ee container (it is therefore not able to lookup services). ManagedThreadFactory

Syntax to no longer be used:

Runnable runnable;
Thread thread = new Thread(runnable);
thread.start();

Syntax to use:

Runnable runnable;
ManagedThreadFactory managedThreadFactory = InitialContext.doLookup("java:jboss/ee/concurrency/factory/default");
Thread thread = managedThreadFactory.newThread(runnable);
thread.start();

ConfigurationServiceBean

Reason for change: InstallServiceBean starts, needs jdo, which needed turbine, which needed InstallServiceBean … Under Wildfly, this produced a lock. In addition, EJBConstants had variables initialized and then changed during startup. And starting with Wildfly produced states where these variables were poorly valued. During the work During the recovery work, a ConfigurationServiceBean was created. This class retrieves the following configuration information:

From InstallServiceBean

• CURRENT_PRODUCT_COMMERCIAL_VERSION
• CURRENT_DATABASE_VERSION
• CURRENT_PRODUCT_VERSION
• CURRENT_DATABASE_SP
• CURRENT_PRODUCT_SP
• CURRENT_PRODUCT_NAME
• CURRENT_PRODUCT_CODE
• FIXS_FILE_NAME
• APPS_FILE_NAME

From EJBConstants

• EAR_FOLDER
• WAR_FOLDER
• EAR_STORAGE_FOLDER
• EAR_CONF_FOLDER
• SQL_SCRIPT_FOLDER
• SQL_SCRIPT_CUSTOM_FOLDER
• INDEXING_FOLDER
• LOG_FOLDER
• WEB_STORAGE_FOLDER
• WEB_STORAGE_CUSTOM_FOLDER
• TEMP_DIR

From ConfigurationHelper

• CORE_RESOURCE_PROPERTIES
• CUSTOM_RESOURCE_PROPERTIES
• PROPERTY_DEFAULT_LANGUAGE
• PROPERTY_SUPPORTED_LANGUAGES
• PROPERTY_ANONYMOUS_FORCE_DEFAULT_LANGUAGE
• CONFIGURATION_HELPER_CACHE_NAME
• CONFIGURATION_HELPER_ALERT_KEY

Import modification of taglibs for JSPs

Reason: with the change of application server, the jstl core taglib is imported automatically. She was in conflict with:

<%@ taglib uri='http://www.axemble.com/taglibs/jstl-c-1.0' prefix='c' %>

It is therefore appropriate to use the taglib core in the JSPs in leiu and place of the former.

<%@ taglib uri='http://java.sun.com/jsp/jstl/core' prefix='c' %>

Removing ExpressionUtil

Reason: with the change of application server, the jsp engine automatically evaluates the contents of ELs. In addition, the ExpressionUtil class is no longer in our classpath. It is therefore no longer possible to evaluate them as ExpressionUtil did. This modification affects you if you had created tags for your jsp.

public class ResourceTag extends TagSupport {
    private String var = null;
    private String id;
    private Object _id;
...


    private void evaluateId() throws JspException {
        _id = null;
        try {
            _id = ExpressionUtil.evalNotNull("resource", "id", id, Object.class, this, pageContext);
        } catch (NullAttributeException ex) {
            // explicitly allow 'null' for value
        }
    }

    public int doStartTag() throws JspException {
        RunData data = (RunData) pageContext.getAttribute(JspService.RUNDATA, PageContext.REQUEST_SCOPE);

        try {
            evaluateId();

            if ((_id == null)) {
                throw new Exception("id param is null");
            }

            String resourceValue = LocalizationMap.getString(_id.toString(), data.getLocale().getLanguage());

            if (var != null) {
                if (resourceValue != null)
                    pageContext.setAttribute(var, resourceValue, PageContext.REQUEST_SCOPE);
                else log.warn(" the value of " + var + " is null ");
            } else {
                try {
                    pageContext.getOut().write(resourceValue);
                } catch (IOException e1) {
                }
            }
        } catch (Exception e) {
            String message = "Error processing ResourceTag, parameter: id='" + id + e.toString();
            log.error(message);
        }

        return SKIP_BODY;
    }
}

public class ResourceTag extends TagSupport {
    private String var = null;
    private String id;
...

    public int doStartTag() throws JspException {
        RunData data = (RunData) pageContext.getAttribute(JspService.RUNDATA, PageContext.REQUEST_SCOPE);

        try {
            String resourceValue = LocalizationMap.getString(id, data.getLocale().getLanguage());

            if (var != null) {
                if (resourceValue != null) {
                    pageContext.setAttribute(var, resourceValue, PageContext.REQUEST_SCOPE);
                } else {
                    LOGGER.warn(" the value of {} is null ", var);
                }
            } else {
                pageContext.getOut().write(resourceValue);
            }
        } catch (Exception e) {
            LOGGER.error("Error processing ResourceTag, parameter: id={} .", e);
        }

        return SKIP_BODY;
    }
...
}

public class EvaluateConditionTag extends TagSupport {
    private String expression;
...

    @Override
    public int doStartTag() throws JspException {
        try {
            expression = (String) ExpressionUtil.evalNotNull("if", "expression", expression, String.class, this, pageContext);
            Object r = ExpressionEvaluatorManager.evaluate("expression", expression, java.lang.Boolean.class, this, pageContext);
            if (r == null)
                throw new NullAttributeException("if", "test");
            pageContext.getOut().write(((Boolean) r).toString());
        } catch (Exception e) {
            throw new JspTagException(ExceptionUtils.serializeException(e));
        }
        return SKIP_BODY;
    }
...
}

public class EvaluateConditionTag extends TagSupport {
...

    @Override
    public int doStartTag() throws JspException {
        try {
            JspApplicationContext jspAppContext = JspFactory.getDefaultFactory().getJspApplicationContext(this.pageContext.getServletContext());
            ELContext elContext = this.pageContext.getELContext();
            ValueExpression valueExpression = jspAppContext.getExpressionFactory().createValueExpression(elContext, this.expression, Object.class);
            Object evaluatedValue = valueExpression.getValue(elContext);
            pageContext.getOut().write(evaluatedValue.toString());
        } catch (Exception e) {
            throw new JspTagException(ExceptionUtils.serializeException(e));
        }
        return SKIP_BODY;
    }
...
}

Escaping Variable Expressions in JSPs

In JSP files, variables that are evaluated by our Java code and not by the Expression Language JSP engine should now be escaped.

<%@ taglib uri='http://www.axemble.com/taglibs/portal-1.0' prefix='portal' %>
<%@ taglib uri='http://www.axemble.com/taglibs/grid-1.0' prefix='grid' %>
<%@ taglib uri='http://www.axemble.com/taglibs/commons-1.0' prefix='cms' %>
<%@ taglib uri='http://java.sun.com/jsp/jstl/core' prefix='c' %>


<script language="Javascript">
    callOnLoad("setWindowTitle('<portal:translation key="
    common.portlets
    " bundle="
    core
    " format="
    Capitalize
    " />')"
    )
    ;
</script>

<portal:entry property="action" var="entryBaseUrl"/>

<cms:connector className="com.axemble.vdocportal.portal2.web.grids.connectors.DesktopConnector"
               var="GCDskConnector">
</cms:connector>

<grid:structure var="GCStructDskPortlets" scope="request">

    <!-- availables filters -->
    <grid:filterable value="label" title="common.displayName" bundle="core"/>

    <!-- actions -->
    <grid:action name="add" title="common.add" bundle="core" multiple="true"/>

    <!-- columns -->
    <grid:column width="1%">
        <grid:field type="checkbox" name="_selected" value="${name}"/>
    </grid:column>

    <grid:column align="center" width="1%" nowrap="true">
        <grid:field type="image" value="button_plus.gif"
                    url="${entryBaseUrl}?_cmp=GCDskPortlets&_evt=add&_selected=${name}" redirect="true"/>
    </grid:column>

    <grid:column title="common.name" width="58%" bundle="core" sortable="true" sortBy="label">
        <grid:field type="text" value="${label}" bundle="core" translate="true"/>
    </grid:column>

    <grid:column title="common.description" width="40%" bundle="core" sortable="true" sortBy="description">
        <grid:field type="text" value="${description}" bundle="core" translate="true"/>
    </grid:column>

</grid:structure>

<grid:renderer structure="${GCStructDskPortlets}" connector="${GCDskConnector}" data="portlets"
               var="GCDskPortlets" template="SelectorLeft" sortBy="label" ascending="true"
               startPosition="1">
</grid:renderer>

<%@ taglib uri='http://www.axemble.com/taglibs/portal-1.0' prefix='portal' %>
<%@ taglib uri='http://www.axemble.com/taglibs/grid-1.0' prefix='grid' %>
<%@ taglib uri='http://www.axemble.com/taglibs/commons-1.0' prefix='cms' %>
<%@ taglib uri='http://java.sun.com/jsp/jstl/core' prefix='c' %>


<script language="Javascript">
    callOnLoad("setWindowTitle('<portal:translation key="
    common.portlets
    " bundle="
    core
    " format="
    Capitalize
    " />')"
    )
    ;
</script>

<portal:entry property="action" var="entryBaseUrl"/>

<cms:connector className="com.axemble.vdocportal.portal2.web.grids.connectors.DesktopConnector"
               var="GCDskConnector">
</cms:connector>

<grid:structure var="GCStructDskPortlets" scope="request">

    <!-- availables filters -->
    <grid:filterable value="label" title="common.displayName" bundle="core"/>

    <!-- actions -->
    <grid:action name="add" title="common.add" bundle="core" multiple="true"/>

    <!-- columns -->
    <grid:column width="1%">
        <grid:field type="checkbox" name="_selected" value="\${name}"/>
    </grid:column>

    <grid:column align="center" width="1%" nowrap="true">
        <grid:field type="image" value="button_plus.gif"
                    url="${entryBaseUrl}?_cmp=GCDskPortlets&_evt=add&_selected=\${name}" redirect="true"/>
    </grid:column>

    <grid:column title="common.name" width="58%" bundle="core" sortable="true" sortBy="label">
        <grid:field type="text" value="\${label}" bundle="core" translate="true"/>
    </grid:column>

    <grid:column title="common.description" width="40%" bundle="core" sortable="true" sortBy="description">
        <grid:field type="text" value="\${description}" bundle="core" translate="true"/>
    </grid:column>

</grid:structure>

<grid:renderer structure="${GCStructDskPortlets}" connector="${GCDskConnector}" data="portlets"
               var="GCDskPortlets" template="SelectorLeft" sortBy="label" ascending="true"
               startPosition="1">
</grid:renderer>

Behavior of the getElementByProtocolUri method changed

Reason: for long uri it is possible to have several data having the same uril (case of workflowInstance if they have the same reference). If several resources have the same uril, then the getElementByProtocolUri method will throw an exception. Previously, the first resource corresponding to the uril was returned arbitrarily.

HttpClient upgrade and removal of HttpUtils

Reason: upgrade from HttpClient 3.1 to 4.5. HttpUtils is strongly linked to the functioning of HttpClient 3.1 (Cf class used in the sendXml method).

Configuration keys for the proxy

• com.axemble.vdoc.http.default.proxy.host
• com.axemble.vdoc.http.default.proxy.port
• com.axemble.vdoc.http.default.proxy.username
• com.axemble.vdoc.http.default.proxy.password
• com.axemble.vdoc.http.default.proxy.dontproxyhosts

Removing the Live Collaboration connector

Reason: This connector is obsolete because Live Collaboration is no longer distributed. It is necessary to remove the uses of this connector before migrating to 16.0.

Removed of BiBoard

Reason: BiBoard is no longer distributed. The com.axemble.vdoc.biboard package is removed. The packaging tasks playing with the creation of a BiBoard table and views are deleted. During migration, BiBoard tables and views are deleted.

Removed setLevel and getLevel methods on com.axemble.vdoc.sdk.utils.Logger

Reason: use the relevant level directly.

Logger logger = getLogger( "com.presentation.Exemple" );
logger.debug("Utiliser");
logger.info("directement");
logger.warn("le");
logger.error("niveau");
logger.fatal("pertinent");

Switching from log4j to slf4j

Reason: the wildfly application server embeds the slf4j lib.

In order not to break compatibility, the log4j-over-slf4j wrapper is embedded.

org.apache.log4j.Logger remains accessible but new loggers should be declared in:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

...

private static final Logger LOGGER = LoggerFactory.getLogger(MyClass.class);

To configure the loggers, it must be done in standalone-custom.xml.

Configuration documentation can be found here

Upgrade jquery 3

Reason: the js jquery lib is upgraded.

You can find the jQuery 3 upgrade guide here .

Our main changes have been to replace :

• the bind/unbind by on/off (bind/unbind are deprecated).
• event submissions made by .focus(),.click(),etc… by .trigger(“focus”),.trigger(“click”),etc…
• additions of event handlers made by .focus(function() {…}),.click(function() {…}),etc… by .on(“focus” ;function() {…}),.on(“click”,function() {…}),etc…

APIs REST

The existing resteasy APIs are deleted.

It concerns:

• AuthenticationService
• BpmService
• DirectoryService
• IOService
• StorageService

They are replaced by the API rest described here;

SDK

System names

The IModule interface now has a generateSystemName method for a label. There was no SDK previously for this feature.

It concerns:

• IDirectoryModule
• IDocumentModule
• IForumModule
• ILibraryModule
• IPortalModule
• ISiteModule
• IWorkflowModule

Example : workflowModule.generateSystemName("a label given for example");

Configuration

The IConfiguration interface now has the following methods:

• InputStream getCustomFile(String… path) throws IOException
• Path getWARFolder()
• Path getCustomFolder(String… path)
• IVersion getProductVersion()

getCustomFile

Allows read access to a file inside vdoc.ear/vdoc.war/WEB-INF/storage/custom.

getWARFolder

Returns the absolute path of the deployed war.

getCustomFolder

Returns the path of a folder inside vdoc.ear/vdoc.war/WEB-INF/storage/custom.

getProductVersion()

Returns an object representing the version of the product.

dependency update matrix