Skip to content

P6 Core 5.20.0

Release date: Tuesday, 23th October, 2018

Documentation can be found here.


Views service

A new service named Views has been created, it will replace the current XML configuration of Views document.

During the migration, the document is split into several views but the views’ content does not change.

Thus with a smaller XML file, it will be easier to edit a view’s configuration.


With the view’s type property, it’s now possible to configure several views for the Workflow Tasks user interface.


It’s advised to keep a backup of the XML configuration of Views file BEFORE the instance migration. In case of trouble, it will be possible to create manually the views from the original XML configuration.

You’ll find the service’s user guide here.

Transactions service

The Messages and the Work Items user interfaces which used to call the Documents web application API are now using the Transactions service.

Although the menu entries on the Portal have been renamed (Messages becomes Transactions and Work Items becomes Workflow Tasks), the user interface’s main behaviour does not change and the Documents web application in the old UI is still available.


Small improvement, the transactions export uses the Jobs Control Panel.

The message DSL binding name has been deprecated, you should now use the new binding name transaction.


BEFORE the migration, you need to change the Transactions and the Workflow Tasks permissions:

  • The messages permission feature has been renamed into transactions.
  • You no longer need the workflow=read and workflowsteps=read permissions to display the Workflow Tasks UI. Only the transitions=allow('WORKFLOW_VIEW'(*)) permission is now required.

You also need to convert the View_[VIEW_NAME] transformer into a script. The server will no longer look for a transformer to get the HTML content of a transaction.

If AFTER the migration you don’t see the Transactions or Workflow Tasks menu entries, restart the Transactions service by:

  • Using Swagger to call the Stop a service and Start a service endpoints in the b2info API.
  • Upgrading to Platform 6 v5.20.1 and use the new DSL method:



If you are in a hurry, instead of converting the transformer into a script, create an intermediary script named View_[VIEW_NAME] which will call the transformer.

Know that the _DEFAULT_ variable was replaced by the xml variable. _DEFAULT_ is still available, but its content-type was changed into text/plain.

Example of the content of the intermediary script for the MessageInfo view:

// Force the content-type of the "_DEFAULT_" variable into "text/xml"
def messageInfo = pipeline.get '_DEFAULT_'
pipeline.put '_DEFAULT_', messageInfo, 'text/xml'

// Call the transformer "View_MessageInfo"'View_MessageInfo')

You’ll find the service’s user guide here.



  • The work item term is renamed into workflow task.
  • The main menu entries are reorganized.
  • Some explanatory links are added where needed.
  • Diagrams are updated.
  • Platform 6 client are renamed to Platform 6 CMB connector and b2box to p6core.
  • The Architecture section is reworked.
  • The Glossary terms are updated.
  • Some service user guides: Frames user guide and Counters user guide are reworked.
  • The Custom service page is updated.


You can now delete a bunch of script’s resources. Use the Ctrl/Command + left click shortcut for single selection and Shift + left click for range selection.

Stored Procedures

The Stored Procedures web application has been removed from the old UI. It is now only available on the Portal.

Workflow Steps

  • In the workflow step XML configuration, the AllowMessageEdit node has been renamed to AllowTransactionEdit.

  • When a workflow task (formerly named work item) was created, the data model’s name used to validate the transaction as defined by the service.workflow.datamodel variable in the application.conf file (by default it was equal to MessageInfo). It is now recovered from the workflow step through a new XML configuration node TransactionDataModel.

Bug fixes

  • During the counters migration, a route named CountersScheduling is automatically created to schedule all the counters with their former CRON expressions. The route is no longer created if there are no counters to migrate.
  • The query generated to search a message according to the messages=allow("MessageInfo"(BRANCH)) permission is now well constructed (there was no issue with the UNIT filter expression).
  • The Routing Orders search fields Concept and Service are now loaded at the service initialisation.
  • The FQDN configuration property is now being normalized in transformers.