TIBCO EBX®
TIBCO EBX® Documentation

5.8.0

Release date: April 3, 2017

Overview of 5.8.0

This release has a particular focus on the user experience improvement, either through built-in components or enhanced customization capabilities. Some of the most notable features are:

Grid edit

This new feature allows to edit records directly in a tabular view. It can be enabled from any custom tabular view.

New user service API

A complete new API is available to provide custom user services integrated in the standard look and feel and benefiting from the existing widget library based on rich data typing. This new API also overcomes the existing limitations by allowing the edition of multiple records, datasets and even non-persistent applicative objects.

Hiding and disabling user services

Thanks to the evolutions of permission rules, it is now possible to dynamically hide the button or the menu item launching a built-in user service, such as 'Create record'. Furthermore, for any user service, either built-in or custom, the permission rule context is richer, hence allowing more precise criteria to hide it in some toolbars or menus, or to completely disable it.

Attention

Before proceeding with the upgrade of an existing environment, ensure that you have carefully read the Version upgrade section.

User experience

Grid edit

On a custom tabular view activating the feature, the end-user can now switch to grid edit, by clicking on the button shown below.

/5.8.0-GridEditAccess.png

The grid edit has a similar look and feel as common spreadsheet software, but it takes advantage of the rich typing and validation feature offered by EBX® to automatically display the relevant user interface widgets and to perform the standard data validation on the fly on user submit.

See also
Note

This new feature currently has some limitations: creation and deletion are not supported; only simple fields can be edited (not groups nor lists); the loaded page size is not yet optimized; the grid edit is not available on a child dataset.

Combo-box

The combo-box widget has been improved with regards to the display and behavior of available choices:

Custom views

The collaborative management and sharing of custom views has been improved in this release.

Permissions

A new administration section is available to configure fine-grained permissions relative to custom views, for instance to define who is able to share views. See Views permissions for more information.

Due to this new permission system, the default permission for publishing views has changed. See Backward compatibility for more information.

Edition

It is now possible to modify custom views directly from the 'Views' administration screen. The following information can be directly updated: the view's label and description, its owner, its group and the 'Share with' field. See Views for more information.

Pagination size

It is now possible to configure a page size limit for custom tabular views. When such a limit is set, the pagination values offered to users will be capped by the specified value. This can be used to keep users from having large tables, thus improving the overall reactivity, in particular for the grid edit.

Recommended and favorite perspectives

Users can now define their favorite perspective: if a favorite perspective has been defined, then this perspective will be selected by default when logging in.

It is now also possible for a perspective administrator to define recommended perspectives by profile: when a user logs in, the recommended perspective will be displayed if no favorite one is defined.

For more information, see Favorite perspectives and Recommended perspectives.

Other improvements

Apply last modifications on association tables

The 'Apply last modification(s)' service is now available on association tables. This action will display in the 'Actions' menu of the association table, provided that a record has been modified.

Displaying a service as a view

A new built-in group is available for user services: @ebx-views. Services included in this group will be displayed in the 'Views' menu of a table.

Page redisplay on form submit

On a form submit, if the page is not closed, it will try to redisplay itself in the same state as before hitting the save button. More precisely, the state of the following elements is now preserved on the redisplay: the selected tab, the last focused input element and the groups expanded/collapsed state (except for groups inside a list). For more information, see UserServiceTab.setId.

Sorting criteria

The sorting criteria applied on a tabular view are now kept in session so that, when navigating back to the view, its former sorting criteria are preserved.

Web component for record validation

A validation service is now also available on a record selection if it is called as a Web component.

User interface – New Java API

User service

A new Java API is available to build powerful custom user services that provide a custom graphical user interface (GUI) and allow users to access specific or advanced functionalities.

For detailed information, see the user service documentation.

Main features are:

Standard EBX® look and feel

It is now straightforward to develop user services with the same look and feel as standard EBX® graphical user interfaces.

Multiple pages and navigation callbacks

A single user service may include multiple pages and control the display and the navigation between these pages, depending on the context (user input, persisted data, etc.). For example, it is possible to implement "wizard"-like user services where the user enters data in a given sequence.

Graphics

This API is not restricted to developing forms and can be used to display graphics, or to mix graphics and forms, according to navigation callbacks.

Toolbars

User services can programmatically define their own toolbars or reuse the toolbars defined in a data model.

Built-in widgets

All widgets available with the UIForm API are also available with user services.

Custom widgets

The new custom widget API is fully supported.

For backward compatibility, the legacy UIBeanEditor API is also supported.

Data validation

User services now fully support automatic input data validation based on data models. The same page can aggregate data from more than one data model.

Multiple records

The same user interface may display multiple records, some for the update and others for creation. These can be from different tables, data sets or dataspaces.

Dataset fields

Display and update of dataset fields is supported. These can be from different datasets or dataspaces.

Dynamic objects

User services now support dynamic objects. This requires programmatically defining a schema.

For more information, see UserServiceObjectContextBuilder.createBeanDefinition.

JavaBeans

Displaying form fields mapped to Java Bean attributes is supported. This requires programmatically defining a schema.

For more information, see UserServiceObjectContextBuilder.createBeanDefinition.

Heterogeneous data display

The same user interface may display fields from multiple records, datasets, dynamic objects or Java Beans.

Programmatically defined schema

It is necessary to programmatically define a schema when using a dynamic object or a Java Beans. Most features available with standard EBX® data models are available: types, labels, descriptions, constraints, validation error messages...

For more information, see BeanDefinition.

Model driven forms

Methods are provided to build totally or partially model-driven forms, that is forms whose layout is the one defined by a schema.

For more information, see UserServiceTabbedPane.newTabsFromPath and UIFormWriter.addFormRowOrGroup.

Database updates

Methods are provided to easily persist data managed by the user service in a single or multiple transaction(s) depending on business needs.

For more information, see UserServiceTransactionManager.

Pagination

A new Java class allows to build paginated views from a request and a page size. This class offers methods such as getting the first and the last pages, or getting the page preceding or following a given record.

For more information, see RequestPagination.

Ajax

A user service can implement Ajax callbacks. A client calls an Ajax callback using an URL generated by EBX®. To facilitate the use of Ajax components, EBX® provides JavaScript methods for sending the request and handling the response.

For more information, see Ajax.

File upload

A user service can display file input fields. HTML forms that allow uploading files are multi-part.

For more information see File upload.

File download

A user service can display URLs or buttons to download files. The actual downloading of a file is under the control of the user service.

For more information, see File download.

Hierarchies and associations

The API now provides more detailed information on the current context for services working on hierarchy views and associations.

Life cycle and threading model

The user service implementation class is instantiated on the first HTTP request and discarded when the current page goes out of scope or when the session times out.

Access to the class is synchronized by EBX®. Therefore, the class does not need to be thread-safe.

For more information, see Life cycle and threading model.

Workflows and perspectives

A user service developed with this API can be part of a perspective or a workflow. It can access information on the current workflow provided by the session interaction.

For more information, see Overview and UserService.

User service declaration

A new Java API allows to declare user services easily and consistently. In previous versions, user services had to be declared and extended by modifying either the data model (XSD), or the module.xml file. While those XML-based ways remain supported for legacy services, the new user service API has given the opportunity to declare any service in a more consistent, simple and modular way.

Main features and benefits of this new approach:

Better modularity

The service is declared by implementing interface UserServiceDeclaration; this class should be packaged near the UserService implementation hence allowing a better modularity and greater robustness, due to Java type checking, than previous declarations in XML.

Centralized definition

The service's unique identifier needs to be defined only once in the Java code (there is no need to duplicate its definition in XML).

Static activation rules

A declaration can easily specify where the user service is activated (namely available) using various criteria. For instance, the declaration of a service working on a record allows to specify inclusions and exclusions criteria on dataspaces, datasets and tables, either by explicit identifiers or by patterns.

Dynamic activation rules

When static activation rules are not sufficient, it is possible to specify rules based on the current context using the new activation and permission rules API. For more information, see ActivationContext.

Simplified declaration for EBX® as a web component, perspectives and workflows

Declaring a user service for reuse as a Web Component in the workflow or in perspectives is now much more straightforward: default built-in input parameters are automatically fed according to its nature; if the service works on a dataset element, it is no longer required to add a serviceLink element in the module.xml. For more information, see WebComponentDeclarationContext.

For more information, see UserServiceDeclaration.

User service activation and permission rules

As detailed below, the Java API used to dynamically enable / disable user services according to the context has been enhanced.

New concept of activation rule

It is now possible to dynamically disable a user service according to the current data space and/or dataset by specifying an activation rule. When disabled through its activation rule, a user service is completely disabled and never displayed in the specified context; for example in the screen to manage user-defined permission rules.

Declaring such rules is only possible with the new user service declaration API.

See ServiceActivationRuleForDataspace and ServiceActivationRuleForDataset for more information.

Richer context for new programmatic permission rules

The new Java interface ServicePermissionRule has been added to provide rules more powerful than the existing ServicePermission. See the ServicePermissionRule for more information.

Declaring such rules is only possible through the new user service declaration API, or by attaching the permission rule to data model elements (see next item).

Attachment of a permission rule to data model elements

The new API also allows to specify, on data model elements, an additional programmatic permission rule for a given built-in or custom user service.

Similarly to AccessRule , the association between the rule, the user service and the data model element(s) must be defined programmatically at the data model level. See the methods setServicePermissionRuleOnNode... on SchemaExtensionsContext .

See user service permission resolution for more information

Custom widgets

A new API to define graphical components, namely custom widgets, is available. A custom widget can be used to customize the look and feel of groups and fields in data models or programmatically defined schemas. This API replaces UIBeanEditor that had many limitations.

Common framework for custom and built-in widgets

For better reuse and integration in EBX®, custom and built-in widgets implement interfaces that inherit from the same UIWidget interface.

Custom layouts

A custom widget can be specifically instantiated and embedded in custom form layouts (UIForm), custom user services (UserService) and in other custom widgets.

Data models and programmatically defined schemas

A custom widget can be specified as the default view of an element (a field or a group that is terminal or under a terminal group) from a data model or a programmatically defined schema. In addition, thanks to the fact that a factory is now specified, it becomes possible to control whether the specified widget is compatible with the relevant element. If this is not the case, an error can be added at the data model level or at the schema compilation time. See the setup method in UIWidgetFactory.

List elements

To facilitate developments, custom widgets for list elements are now handled by a distinct interface, UIListCustomWidget, while non-list elements must be handled by UISimpleCustomWidget.

Schema introspection

To introspect a schema, the new method SchemaNodeDefaultView.getWidgetFactory has been added.

For more information, see UICustomWidget and Default view Widget.

The old UIBeanEditor is now deprecated

Custom form

The custom layouts (UIForm) and the new user service API (UserService) share the common interface UIFormWriter. It has been enriched with the following features:

Additionally, the last selected tab of a tabbed pane can now be retrieved by invoking the method getPreviousTabSelected on one of the following interfaces: UIFormContext, UserServiceSetupDisplayContext or UserServicePaneWriter.

Button icons

Three new button icons are available in the UIButtonIcon API, underlined in the screenshot below.

/5.8.0-ButtonIcons.png

See UIButtonIcon for more information.

Workflow

Better user experience on Accept and Reject

When the user accepts or rejects the work item, but the mandatory comment is unset, the comment pop-up is now automatically opened. A new button is available in the comment pop-up to directly terminate the work item according to the initial decision.

/5.8.0-SimplifiedAccept.png

API to manage the life cycle of work items

The life cycle of work items can now be managed directly by means of the Java API. It allows to allocate work items, start them, and accept or reject them, under certain conditions. The following methods have been added:

Thanks to this new API, many scenarios bypassing the standard workflow inbox can be considered. For example, from a domain-related table and in a single action, the user is able to accept or reject multiple work items (a record in this table having a link to its associated work item through the persisted work item key).

Other workflow API

Data modeling

New built-in data types

Dataspace reference

The new data type osd:dataspaceKey has been added to reference dataspaces within an EBX® repository. If a field in the data model uses this type, then the end-user is able to reference a dataspace using a new input field. This new input field displays the dataspaces that can be referenced according to the current repository and the field's constraints.

See osd:dataspaceKey for more information.

Dataset reference

The new data type osd:datasetName has been added to reference datasets within an EBX® repository, in the context of a dataspace. If a field in the data model uses this type, then the end-user is able to reference a dataset using a new input field. This new input field displays the datasets that can be referenced according to the current repository and the field's constraints.

See osd:datasetName for more information.

Color value

The new data type osd:color has been added to handle colors. The associated 'color picker' widget allows the end-user to choose a color in the hexadecimal RGB format.

See osd:color for more information.

Replication API

Based on the replication units defined in the data model, replica tables are generated in the database schema. The replication API has been enhanced so as to retrieve information related to these tables.

See Replica for more information.

Refresh policy

The ReplicationUnit API has been improved to be able to retrieve the refresh policy of a replication unit.

See ReplicationUnit.getRefreshPolicy for more information.

Data services

Built-in RESTful services

The built-in RESTful services have been improved for the following operations:

Delete operation

The 'delete' operation now supports multiple rows of records in the request body. This operation will delete several existing records in a single transaction.

See Delete operation for more information.

History operations

A new 'history' category is now supported. Several new operations are available for selecting and counting the history content of datasets, table records and record fields.

See Operation category for more information.

Select operation

The 'select' operation on table now allows applying:

See Table parameters for more information.

Simple data types

The new built-in data types: osd:color, osd:datasetName and osd:dataspaceKey are available for all operations.

See Content of simple type for more information.

Java API

Provides Java utility methods for REST encoding.

See RESTEncodingHelper for more information.

Naming of model-driven operations in WSDL

If two tables had the same name in the data model, for instance, /root/domain1/product and /root/domain2/product, then it was not possible to generate the WSDL from the data model because of naming conflicts (bug #5308). In the data model, it is now possible to assign a unique name to any table, so that this name will be used to generate the associated data service operations, by suffixing the operation name.

See Data services for more information.

SOAP operations

SOAP operations have been improved for the following operations:

Customizing the WSDL target namespace

A new technical parameter allows to change the value of the targetNamespace attribute in generated WSDLs. When generating a WSDL through:

  • The user interface, this parameter is present in the new 'Advanced configuration' section existing for each data service.

  • HTTP requests, this parameter can be set with a new optional query parameter called targetNamespace.

    See Parameters for more information.

Comparing generated WSDLs

The content of two WSDL generations can now be compared, in the following order:

  • For WSDLs on data and directory, the content keeps the data model structure.

  • For all WSDL types, operations are sorted by name.

Simple data types

The new built-in data types: osd:color, osd:datasetName and osd:dataspaceKey are available for all operations.

Miscellaneous

Number formatting policy

It is now possible for a user to modify the separators that appear in the formatted numbers by defining the attributes groupingSeparator and decimalSeparator in the formatting policy file frontEndFormattingPolicy.xml.

See Value formatting policies for more information.

Decimals having zero fraction digits are now formatted differently when using the method SchemaNode.formatToXsString(Object aValue). The following zero(s) of the fractional part are omitted. This formatting is compliant with the W3C XML Schema type for performing the Decimal-to-String conversion.

New XPath functions

Two new XPath functions are now available:

See XPath supported syntax for more information.

Request API to activate sort on labels and record-level permission rules

The setLocale and setSession methods have been added to the Request interface.

They allow activating the permission rules on Record, as well as sorting localized labels according to a given user's locale.

Note

This feature has been implemented since version 5.5.0 and has been in use since then. It had been omitted from the release note at the time of that release.

Privileges in Trigger and Procedure context

Because the only method provided to bypass permissions in the Trigger and Procedure contexts was the setAllPrivileges() method, developers had to disable permission checks for all nodes as soon as they wanted to set a technical value.

A new method ValueContextForUpdate.setPrivilegeForNode has been added to grant privileges, only for required nodes.

Duplicating a record with read-only fields

Since version 5.6.1, duplicating a read-only field was not possible, since fields without write access were cleared at the end of the handlNewContext trigger.

When used in the handlNewContext trigger, the new method ValueContextForUpdate.setPrivilegeForNode allows to bypass this behavior, only for required nodes. This evolution corrects the bug #23037.

Validation messages threshold

The property ebx.validation.constraints.messages.threshold has been added to the EBX® main configuration file (ebx.properties). It allows to specify a validation message threshold that is applied to each constraint of a data model. The benefit of this new property is to not stop the validation of a dataset when this threshold is raised by a constraint.

This evolution corrects the bug #17839; as a consequence, the property ebx.validation.messages.threshold is no longer supported. See Backward compatibility for more information.

The ValidationReport API has also been enhanced to provide information about the constraints that have reached the threshold. See ValidationReport.hasConstraintsWithTooManyMessages for more information.

Version upgrade

In addition to the information provided in this release note, the following chapter provides an exhaustive list of the new Java APIs published since the release of the 5.7.1 version.

Supported environments

The chapter Supported environments has been updated to reflect the necessary upgrades detailed below. The two first items concern the application server.

Java 6

Java Runtime Environment requirement becomes JRE 1.6 or higher versions.

The JavaBeans Activation Framework is now included in the JRE; as a consequence, the third-party library named activation.jar should be removed from the 5.8.0 installation environment.

Servlet 3.0

The deployment descriptor (web.xml) for EBX® web applications has been modified to comply with the Servlet 3.0 or higher versions specifications.

SQL Server 2008R2

The database SQL Server 2008 is no longer supported, the minimum required version for SQL Server has been upgraded to 2008R2.

Firefox ESR 45

Firefox ESR 38 is no longer supported since June 7, 2016. The currently supported version is Firefox ESR 45. As a consequence and from this version of EBX®, the officially supported version of Firefox ESR is 45. See Mozilla Firefox ESR for more information.

Backward compatibility

Custom view publication

As a consequence of the introduction of the new permission system for custom views, non-admin users can no longer publish their own views.

Previously, a built-in administrator could publish any view while other users could only publish their own views.

With the new permission system, a user can be allowed to either share any view or zero view of a given data model. If no permission is set for a given user, the default permission is defined as follows: built-in administrators can publish all views while other users cannot publish views.

Method getWebNameForPath in a UI Bean

The method UIContext.getWebNameForPath(Path) supports only relative paths for record nodes. Path to record nodes must always be relative to the current one. Absolute paths are interpreted as paths to instance nodes. For more information, see UIContext.getWebNameForPath.

Workflow - Accept and Reject by API

As a consequence of the bug fix #24899, the accept and reject actions by API can be unauthorized for the following reasons: a mandatory comment is unset, a specific constraint is not valid or a workflow trigger throws an exception. These checks were not performed in previous versions (5.7.1 fix D and later), this is why a change of behavior may be noticed.

Workflow - mails

As a consequence of the bug fix #22568, the URL parameter set in the workflow configuration shall be reviewed.

Technical configuration for emails

As a consequence of the requirement of Java Runtime Environment JRE 1.6, issues may occur when sending emails. The migration from JRE 1.4 to JRE 1.6 and above, if not specified, will take into account IPV6 routes for mails instead of IPV4 (default configuration of JDK 1.4 for the JavaMail libraries). In that case, it is necessary to double-check the network configuration in order to ensure IPV6 is enabled. Another solution would be to indicate to the JVM to explicitly use IPV4 instead, by setting the following JVM argument to true: -Djava.net.preferIPv4Stack=true.

User services in the Data Model Assistant

It is now recommended to use the new UserService API to define user services since it offers a better integration and more features than ServiceContext; these new services are directly registered through the Java API. As a consequence, in the Data Model Assistant, the section 'Configuration > User services' is no longer displayed by default on new data models and on existing data models that do not already declare user services. However, the new property 'Enable user services (old API)' is available in the section 'Global properties', to enable the definition of old user services in a data model. See Data model properties for more information.

Data services - SOAP delete operation

When the predicate does not match any record, a data service exception is returned with a dedicated message, instead of the value code 00. See Delete operation for more information.

Data services - improved checks for SOAP table operations

As a consequence of the bug fix #24590, the table node permission for the request session is now checked when performing an operation on a table via SOAP. Although this check should have been implemented from the beginning, existing data services could be impacted by this change in behaviour.

Dependencies on inherited fields

As a consequence of the bug fix #24862, constraints defined on inherited fields are now automatically set to the Unknown dependencies mode. Consequently, if existing data models define some constraints that attempt to specify an explicit dependency to an inherited field, an IllegalArgumentException will now be thrown. See DependenciesDefinitionContext for more information.

History on inherited fields

As a consequence of bug fixes #24504 and #24504, the history no longer stores inherited values. Both dataset inheritance and field inheritance are concerned. In the graphical interface, inherited values are replaced by an appropriate label, which shows that a field had an inherited value when an operation on a record was historized. In the database, inherited values are replaced by nulls. The user can deduce, by looking at the operation code associated with the functional field, if the null denotes an inherited value. The change will not affect history records that are already historized and stored in the repository.

Validation message threshold

As a consequence of the bug fix #17839, the property ebx.validation.messages.threshold is no longer supported. It has been replaced by the ebx.validation.constraints.messages.threshold property that allows to define a validation message threshold that is applied at the constraint level. That is, the validation message threshold is no longer globally applied to a dataset, but to each constraint defined in a data model. As a consequence, an error will be raised on existing environments that use the ebx.validation.messages.threshold property. Furthermore, is it recommended to adapt the new validation message threshold since it is applied for each constraint of a data model.

How to upgrade an installed environment

In order to upgrade your version of EBX®, perform the following steps:

  1. Backup your repository, including the RDBMS and the directory ebx.repository.directory.

  2. Replace the *.war and ebx.jar files on your application server.

Attention

If using EBX® add-ons, ensure that the versions of the add-ons are compatible with EBX® version 5.8.0 before upgrading. For the backward compatibility of the add-ons themselves, consult the release note of each add-on.

Once an EBX® repository has been used with this version, using it with a previous version is not supported. Consequently, you must create a backup before upgrading, as described above, in order to maintain the possibility of downgrading later.

Bug fixes

Core engine

Data modeling

Data services

Dataspaces & History

Data validation

Data views

Data workflows

Distributed Data Delivery (D3)

Documentation

Import / Export

Messages & i18n

Miscellaneous

User interface

Users & Permissions