This topic explains other topics that are useful for developers working with XperienCentral.
In This Topic
Developing Dashboard Plugins for the Monitoring Framework
wm-addon-monitoring Git repository there is sample code that shows how to develop your own dashboard plugin. This demo code is located in the
wmaxmfdashboardplugindemo folder. This code (mainly written in Angular Typescript) will, when deployed,show up as a separate tab in the Monitoring Dashboard. You can use this project to get started creating your own plugin(s).
- The main
pom.xmlof the bunde contains all the logic needed to build the Angular code for your plugin. It is a variant on the code that can be found in other bundles that use Angular-based code.
The code in the bundle is split into separate Java and Angular parts:
- The Java part that implements the
XMFDashboardPluginsProviderinterface via the OSGI Activator.
- The Angular part that implements an Angular library that can be loaded at runtime.
This class implements the
getDashboardPlugins() method that is called to by the monitoring framework on bundle load to determine which dashboard plugin(s) are contained within the bundle and how to load them correctly. The following information about the dashboard plugin has to be supplied here:
exportedModule— The module name that this library exports as a bootstrap (case-sensitive).
routedpath— The path under which the the Angular router should add the dashboard plugin in the main menu of the Monitoring Dashboard. Note that no conflicting paths are allowed so be sure to use an exclusive name for your plugin.
translationPath— The path where i18n JSON files for the ngx-translate mechanism are located. These translation files can be used for static translations in the tab you add.
menuNames— A set of names for your dashboard plugins, one for each locale you support (typically
menuIcon— The icon to display in the main menu of the Monitoring Dashboard. It is the technical name of the Google material icon to use.
The project for the Angular library that makes up the visual part of the plugin is a standard Angular library that can be created via the Angular CLI (see https://angular.io/guide/creating-libraries).
It consists of
- One module that ensures static translations via ngx-translate can be accessed (in the demo:
- One main component that is rendered by Angular as the content of your added tab in the dashboard (the demoplugin.component in the example).
In the main component you can add new custom indicators.
Generic code for the Monitoring Dashboard is located in the
xmfdashboardframework package (version 1.0.1) which is installed via npm (the package is published on our local Nexus server). When changes in the generic code are required, this should be done in the
xmfdashboardframework package and the build result should be published to NPM with a new version number. Normally this should not be required in order to create a plugin for the Monitoring Dashboard.
Two indicators are added by the example (http-backend-request-multinode-card and clusterinfo-card) which shows you how you could create indicator cards.
All the indicator cards are developed in the Angular Material style for the cards themselves, Angular Flex layout is used to place them on the canvas (see https://material.angular.io/ and https://github.com/angular/flex-layout). Please note since you are developing in an Angular library that is loaded at run-time by the main Monitoring Dashboard panel, you do not have the freedom to import anything from the npm. The main dashboard must be able to resolve the imports required. The following are supported:
'@angular/core' '@angular/common' '@angular/router' '@angular/flex-layout' '@angular/material' '@ngx-translate/core' '@angular/cdk/overlay' '@angular/common/http' 'ngx-cookie-service' 'rxjs' 'rxjs/operators' 'chart.js' 'ng2-charts' '@ngx-translate/http-loader'
Translation files for ngx-translate should be added under the assets folder (in the demo found under
The following REST services are offered by the
ClusterEventRestService— Retrieves the available cluster nodes in the installation.
IndicatorSetRestService— Retrieves indicator sets and the measured values in these sets as offered by the
IndicatorSetConfigurationRestService— Retrieves and updates the configuration parameters of indicator sets as offered by the
LocaleRestService— Retrieves the current locale in the edit environment.
WebsitesRestService— Retrieves the available websites in the installation.
The following Angular/web-components are offered by the
AbstractMultiValueCard— The base-class that implements a basic pattern for handling indicator data
DoughnutGraphComponent (xmf-doughnut-graph) — Used to draw a doughnut graph
xmf-pie-graph) — Used to draw a pie graph
IndicatorCardContentComponent (xmf-indicatorcard-content) — Used as a wrapper for the actual card content with a conforming height and look-and-feel
xmf-indicatorcard-header) — Used as the default header for a card showing settings and refresh icons
MultiValueCardComponent (xmf-multivalue-card) — Used to display a default styled card with a row or column of indicators
MultiValueContentComponent (xmf-multivalue-content) — Used to display a row or column of indicators
xmf-singlevalue-content) — Used to display a single indicators
When developing a new card the following pattern can be followed. This is a class that implements the data layer of the indicator set to be visualized and it extends
<Specific content of the card>
wmaxmfdashboard main dashboard, several examples can be found on how to use the
Developing Your Own Indicators
The explanation above only describes how to create a Monitoring Dashboard plugin but does not cover how to develop your own indicator set(s). That is done entirely in Java. See the
wmaxmfindicators bundle for an example of how to create your own custom indicators. As a starting point you should implement an
XMFIndicatorProvider that enables the registration of your custom indicators. See the file
wmaxmfindicators. Refer to the Javadoc for
wmaxmfapi in the
wm-addon-monitoring package for the interfaces offered by the framework.
Custom Content and the Is Used in Widget
The Is Used In widget shows an overview of content items that are using the currently selected content item. In XperienCentral versions 10.22.0 and earlier, the usage of content items referring to a custom content type was not detected for content items from a custom content type, The widget would only show a count of 0 used content items. The API of several content items in XperienCentral has been extended with a method for implementing this used-in relationship for custom content types. This functionality is available via the new abstract method:
For all custom content items that implement or extend one of the following interfaces and classes:
The result of this method is the list of used content items (as defined by the projects requirements). The following is a code snippet from a custom content type (extending
MediaItemVersion) which implements the method
Use in Page Metadata
It is also possible to define this method for custom page metadata. The method must be added to the page metadata class. Additionally, an adapter must be implemented that supplies the result of the method to the indexer service. The following are examples of implementations of both the method definition and the adapter:
Developing Custom Bulk Actions
Beginning in XperienCentral R28, it is possible to define your own bulk actions for content items. You can, for example, add the possibility to publish multiple content items at once, change the publication or expiration date for a set of articles in one go, and so forth. The example custom bulk action implementation described below is added in a new XperienCentral plugin. It is also possible to add a custom bulk action to an existing plugin.
The bulk actions available in XperienCentral by default are delete and export. The delete bulk action is available out-of-the-box and the export bulk action is added when you install the Connector API add-on. Bulk actions are accessible in the Actions menu in Advanced Search:
Bulk Action Factory Implementation
Each bulk action is identified by an action type. This is a unique ID string such as "exportToExcel". Every instance of a bulk action type is created by a custom bulk action factory. The implementation of this custom bulk action factory is also responsible for registering the custom bulk action in XperienCentral. Every custom bulk action factory must extend the class
BulkActionFactory. For example:
The registering and unregistering of a bulk action is performed using the
onStop methods of the factory implementation via the bulk action service injected by OSGi:
The Actions drop-down menu in Advanced Search is populated with labels provided by all bulk action factories registered to the bulk action service. The method
getActionLabel must be overridden in your factory:
Instantiating a bulk action is accomplished by calling the
createBulkActionInstance method. You should override this method in your custom factory to return the correct bulk action type:
A method call to
createBulkActionInstance will trigger the creation of a new bulk action of type custom with possibly its own parameters such as an Excel service like that shown in the example above. This method call will usually come from the bulk action handling mechanism in XperienCentral.
Bulk Action Implementation
To implement the bulk action itself, your bulk action class must extend
AbstractBulkAction and define the members and methods it needs for its custom functionality:
The constructor of your class should look like this:
actionIdentifier parameter is the
actionType identifier string. The
items parameter is a list of item identifiers like "articleversion-14" that were selected for the bulk action. The
frameWorkDependencies parameter is a collection of services in the framework that are made available for use in your bulk action by the bulk action service. The
locale parameter is the locale of the content editor. All these parameters are always passed on by the bulk action service when creating a bulk action. The last parameter,
excelService, is a custom parameter used in this example. The call to the super constructor ensures that the bulk action is initialized properly and that the bulk action framework can handle the action.
Next, the actual validation code and business logic for the bulk action needs to be implemented. This is done using the methods
postProcess. The method
checkPermissions is called after the bulk action selection is made in order to check whether the bulk action can be executed on the selected items. The method is called for every item in the selection. To only allow the action to be executed on items with sufficient edit permissions, you could implement the method like this:
treat is called in order to execute the actual action on one content item in the bulk action. The bulk action framework will iterate over the selection of items and call this method for every item. An implementation of a bulk action performing a state change on every content item of the selection, for example to publish an entire content set at once, could be implemented as follows:
preProcess can be overridden in order to prepare and initialize the bulk action. The method
postProcess can be overridden in order to perform additional work after all content items are processed. These two methods together with the
treat method can be used to export data to Excel, for example:
Defining the Bulk Action Factory Component
The bulk action factory is a service bundle and must be defined as such in the Activator class of your plugin. Its definition will look something like this:
Credentials Service Provider
In a standard installation, XperienCentral users are managed in the Authorization component. Along with the Authorization component, there are two types of credentials sets that are not targeted at the editorial tasks but are infrastructure-related. By default these credential sets are managed by the following properties in the XperienCentral Setup Tool (General (R30 and older) tab):
These credentials sets are for:
internal_http_authentication_password / internal_http_authentication_usernameneeded for
Because these credentials sets can be managed in an organizational credential storage system external to XperienCentral, you can create an integration with this thereby removing the need to fill in these credential properties in the Setup Tool.
This can be accomplished via your own integration component by creating a plugin that implements the Credentials Service Provider. When there is no plugin active that implements the credentials services, a look-up is done on the settings
internal_http_use_form_authentication in the "application_settings" section in the General (R30 and older) tab of the Setup Tool. If a plugin is active that implements the XperienCentral credentials service, the username/password combination from the plugin is used to authorize the user.
When a credentials provider plugin is created, the service in the activator needs to implement the CredentialsProviderService and CredentialsProvider classes. The following is an example implementation of a credential provider.
Note that other credential sets that are infrastructure-related that are not already covered via the ones above can also be run though the credential provider logic, however in this case you need to accommodate this yourself. For example:
Depending on the application server being used, a credential provider or -vault may be standard within the application server such as inside IBM WebSphere or another product like CyberArk can be used for this functionality (in case of Tomcat or Jboss).
Property Editors are used to facilitate conversions between a complex type and String. Posted values from an HTML form will usually be converted to a String by the servlet engine. Spring MVC offers a way to convert incoming Strings to complex types; it also converts complex types to Strings when the response is sent back to the browser. Spring MVC offers this functionality through the Property Editors. The Spring MVC and the XperienCentral platforms already have a few default Property Editors for the following types:
- All primitive types plus their auto-boxed equivalents;
- Date (in the format of “dd-MM-yyyy” or “dd/MM/yyyy”).
To add a custom Property Editor, follow these steps:
- Implement a custom Property Editor.
- Register the custom Property Editor in the
In the following parts of this topic, an example of a custom Property Editor is shown based on the Calendar type. By default, there is no support for a property of type Calendar although it might be of interest for plugin developers.
Implement the Custom Property Editor
To implement a custom Property Editor, a class is needed that:
- Implements the
PropertyEditorinterface; usually this is done by extending the
- Implements the methods
The implementation of the
CustomCalendarEditor looks like this:
Register the Custom Property Editor
Now that the custom Property Editor is implemented, it has to be registered with Spring MVC. This is done in the
initBinder method; this method is placed in the controller of your component (for example,
CustomElementController.java). The registration looks like this:
The Custom Property Editor in Action
Once the custom Property Editor has been created and registered, it is ready to use. This means that it is now possible to use the Calendar type for properties in the Java code. Below are some code snippets that illustrate the use of the custom the Calendar type Property Editor that was created in the above example.
Code in the edit-JSP (e.g.
Code in the
FormBacking object (for example,
The result as seen in XperienCentral:
Validators can be used to validate user input and to generate client side error messages when invalid input is provided by a user. Validators prevent users from entering invalid data. Validators are Java classes that implement the
org.springframework.validation.Validator interface. This interface provides two methods:
supports method indicates which classes the validators can handle. The
validate method performs the actual validation. The Sprint MVC framework provides API methods that make it easy to perform this validation, for example
To register the validator it must be added in the
initBinder method of the controller using the
addValidator method. You should only add the validator once per lifetime of the controller instance. So if you have a stateful controller (which is the default), be sure to instantiate and register the validator only once. If you unconditionally add the validator in the
initBinder method, the validator will be invoked twice on the second HTTP request, three times on the third, and so forth.
The code snippets below provide an example of using a text validator for a custom element that rejects any empty text value or value that equals “not empty”:
The validator class:
As a result the message “Text may not be empty” will be displayed if the user input was invalid:
The java.net package part of the Java API provides a basic set of classes which can be used to handle HTTP GET and POST requests. However, in some cases a more powerful HTTP client API is needed. The commons HTTP client (
org.apache.commons.httpclient.HttpClient) may be a better alternative for those cases.
To incorporate the commons HTTP client jar files into a plugin, modify the
pom.xml file in order to define a dependency with the commons
HTTPclient artifact. For example, define the following dependency:
Without further changes however, the plugin will throw a runtime error upon the invocation of the HTTP client because of a conflict in commons logging:
Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.
The reason for this is that the dependency above will cause the
commons-logging artifact to be included in the plugin since it is required by the HTTP client artifact. However, the XperienCentral framework also exports the commons logging package which causes the mismatch.
In order to resolve this issue, an additional dependency with the
commons-logging artifact must be defined with a scope provided so that at runtime the
commons-logging classes exported by the framework will be used instead:
XperienCentral offers standard HTTP proxy configuration settings. These settings are configured using the XperienCentral Setup Tool (
/web/setup). The settings are made available through the default system networking properties. For complete information about these properties, go to the URL http://docs.oracle.com/javase/8/. The example below shows how you can apply these settings in XperienCentral in combination with HTTP clients version 2 and 3.
Creating an Extension for the User Profiles Component
The XperienCentral component User Profiles can be extended via the API in order to add custom fields and tabs to the default user profile information. In addition to adding extensions to the user profile information, you can also manage users, groups, newsletter subscriptions, permissions, and banned and reserved words via the XperienCentral API. This makes it possible to enhance the functionality contained within the user profile component for your particular implementation. All data in custom fields and tabs can also be exported together with data in the default user detail fields using the provided export functionality in the User Profiles component.
The packages containing the interfaces that manage users, groups, and user profile settings are:
nl.gx.webmanager.services.defaultprofileprovider- Contains the interfaces for managing user profile data in the default user profile as provided by XperienCentral.
nl.gx.product.wmpuserprofiles.api- Contains the interfaces for managing custom sub-tabs and permissions for the ‘User Profiles’ component.
nl.gx.webmanager.services.usermanager -Contains the interfaces for managing users, groups, and newsletter subscriptions.
nl.gx.webmanager.services.usermanager.settings -Contains one interface for managing reserved and banned words.
Generating the Sample Profile Extension Plugin from the User Profiles Archetype
Included with XperienCentral is a sample plugin that extends the user profiles functionality by adding a field to the [User Details] tab (view extension) as well as a new tab named [MSN Details] with one field. By generating a sample profile extension plugin from the archetype, you can see a working example of how extra fields and tabs can be added to the default user profile as well as how the extra data can be exported.
To generate the sample plugin, execute the following command from a command prompt. In the example below, the command is issued from the root of the XperienCentral installation (where the
settings.xml file is located). You can also execute this command from a different location as long as you provide the absolute path to the
mvn -s settings.xml archetype:generate -DinteractiveMode=false -DarchetypeGroupId=nl.gx.webmanager.archetypes -DarchetypeArtifactId=webmanager-profileprovider-archetype -DarchetypeVersion=x.x.x -DgroupId=nl.gx.product -DartifactId=customprofile -DpackageName=nl.gx.product.customprofile -Dclassprefix=Custom
where x.x.x is the version of XperienCentral you are using.
As a result, the following folder structure is created containing the source code for the
customprofile sample plugin:
UserManagement Interface Methods
In order to create a custom extension for the user profiles functionality, you must use the following XperienCentral API methods to implement the Profile Extension Provider interface. The following code is taken from the file
The Profile Extension provider contains the following:
- Callback methods that create and delete users
- Methods to retrieve and update user profiles
- Methods for exporting user profiles
Add your own methods that implement this interface. In the file
src\main\java\nl\gx\product\customprofile\profileprovider\CustomProfileProviderImpl.java, the following code makes the profile provider available to the framework:
Custom Profile Declarations
In the file
src\main\java\nl\gx\product\customprofile\profileprovider\CustomProfileImpl.java, the following code implements the custom profile and initializes the new fields:
The following code sets and retrieves the data in the new custom fields:
Adding a Custom Tab to the User Profiles Component
The following code shows how to add a custom tab to ‘User Profiles’ component. The code is taken from the file
If you add more than one sub-tab, the order that they appear from left to right is controlled by the custom tab’s rank. The sub-tab with the lowest rank value appears first and the rest follow in order from left to right.
The following code, taken from the file
src\main\java\nl\gx\product\customprofile\viewextension\impl\CustomSubTabFBO.java, shows how to extend the panel tab’s form backing object to include the new field:
The following code, taken from the file
src\main\resources\editpresentation\customprofilesubtab.jspf, implements the rendering of the new field:
Adding a Custom Field to the User Details Tab
Custom data fields can be added to the [User Details] tab in order to extend the detailed information you want to store for each user. The following sample code, taken from the file
src\main\java\nl\gx\product\customprofile\profileprovider\impl\CustomProfileImpl.java, shows how to add a new field, "ICQ Address" to the [User Details] tab.
The same custom profile is used for the custom tab extension and extending the [User Details] tab.
The following code, taken from the file
src\main\java\nl\gx\product\customprofile\viewextension\impl\CustomFBO.java, shows how to extend the panel tab’s form backing object to include the new field:
The following code, taken from the file
src\main\resources\editpresentation\customprofileview.jspf, implements the rendering of the new field:
Exporting Data from Custom Fields
In order for XperienCentral to be able to export data from custom fields, you must declare the new headers that need to be retrieved during the export. For example:
The following code passes the values retrieved from the custom fields to the export function:
This implementation comes from the
CustomProfileProviderImpl interface. The methods are part of the
Creating Workflow Action Constraints
A workflow action constraint puts a restriction on the transition from one state to another for content items in a workflow. The constraint is based on a specified property or condition belonging to a content item. For example, a constraint can prevent a content item from transitioning from the "Planned" to the "Published" state if it does not have a title or if it does not have an expiration date assigned to it. A constraint can be global and apply to all content types or you can select the specific content type to which it applies.
Developers can create their own workflow action constraints by implementing and registering the
WorkflowActionConstraint interface as a service. The interface is implemented as follows:
mediaitem archetypes provide an example workflow action constraint. This constraint prevents a content item from being published if it has no title.