Skip to content

Our Blog

Pixel Core Integration Platform User Interface

General Overview

Pixel Core Integration platform encloses many ready to use components:

  • Organization
    • Permissions
    • User Roles
    • Users
    • Clients
  • Types
    • Client Types
    • Contact Types
  • Reports
    • Report Types
    • Report Editor
    • Report Browser
  • Logging
  • Application Preferences
  • Schedules
  • Scripts
  • Languages

Pixel Core Integration Platform is multilingual by default. It allows for interface and data localization. Active languages are  selected in Languages manager. Most of interfaces will enable configuration of data in different languages. This data will be displayed later in language chosen by user (see Multilingual Support).



With the technology improvements and introduction of computers in every business area, the complexity of a system administration tasks has greatly increased. Even in a midsize network, it is quite a difficult task for a single person to cover all the aspects of system administration. Pixel Core Integration Platform answers this concern through its User & Role Management module; delegating routine activities to chosen users with well-defined permission levels. It restricts the access to various system aspects to authorized users with the Role Based Access Control (RBAC) approach.

Administrators can tailor-make any number of roles in Pixel Core Integration Platform and give them permissions of your choice based on your personalized needs. These roles can then be associated with individual functions of Pixel Core Integration Platform and products built on top of it.


All server side functions/methods are being protected by associated security. In general there are three permission type: READ, WRITE, DELETE. Each module has multiple methods, such as list*, get*, save*, delete*. Methods like list and get are protected by READ permissions. Save methods are protected by WRITE permissions and delete methods are protected by DELETE permissions. Of course, there is no limitation on types of permissions. Some custom functions could be protected by other permissions (for instance ROLE_…_EX – for execute or any other)

For example, UserService allows to manage users and hence all permissions are named ROLE_USR_[X] where X is either R, W or D.

Figure 1 Permissions


Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members or staff (or other system users) are assigned particular roles, and through those role assignments acquire the computer permissions to perform particular computer-system functions. Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user’s account; this simplifies common operations, such as adding a user, or changing a user’s department. If system is integrate with corporate LDAP/AD then roles are mapped to LDAP groups.

There are two predefined roles

  • ADMIN – contains all available permissions and allows access to all functionality
  • BASIC – contains only basic permissions that allows user to login and change password and default language.

Figure 2 Roles


Besides Role Based Access Control, which governs static access to specific methods or functions, Pixel Core Integration Platform enables access to specific data based on associated client. By default platform is configured with one SYSTEM client. Each user in the system must be associated with one client. Users associated with SYSTEM client have access to all clients’ data. As an example, lets’ assume that there are two clients MERCHANT_A and MERCHANT_B and both have list of products. For sake of this example, each product will have a prefix with A for MERCHANT_A (A_PRODUCT1, A_PRODUCT2) and B for MERCHANT_B (B_PRODUCT1, B_PRODUCT2). Then the same call to list products will return following


Each client must have client type assigned. Client type as well as other dictionary based parameters are configured via Types menu that will be discussed later.

Figure 3 Client Details

Each client could have multiple addresses. Address Types, Street Type, Direction and Country are also defined in associated Types editor.

Figure 4 Client Address

Besides multiple addresses, client might have multiple contacts of different types. It is important to understand relationship of entities within contact. By default, there are number of contact types, defined also in Types dictionaries – TECHNICAL, ADMINISTRATIVE, PRIMARY. There is not limit or constraints on contact types. Each contact could have multiple Contact Entries of different types. The entries could be of type Email, Phone, Fax, Skype, Etc. In addition to Contact Entry Type each entry has sub category – Kind. Contact Kind defines to what this type is – Home, Work, Mobile, Other. Contact Types and Kinds are also configured via associated editors within Types menu.

Figure 5 Client Contacts


This administrative interface establishing a user’s rights to information within an organization. The management part deals with adding user names and passwords to various platform resources along with the assignment of rights to data. The user provisioning deals with planning, setting up and configuring the hardware, software and networks that actually deliver access to the data and network resources for the users. User management and provisioning is also called “identity management.”

Pixel Core Integration Platform supports two types of identity management

  • Internal – roles and password are managed within systems’ database
  • LDAP/Active Directory – roles and passwords are managed within external LDAP system and could be either managed via Pixel Core Integration Platform UI or external tools.

Client assignment is mandatory to each user. This allows for information segregation per user. See Clients paragraph for more detailed explanation of data segregation.

Figure 6 User Details

Roles tab provides an ability to assign which roles user belongs to. In case of LDAP user kind it is possible that information on this screen is not editable if LDAP server is not provisioned for write access.

Figure 7 User Roles

Following menus and functionality is available when user has only BASIC role

Figure 8 Menus for user with BASIC role only

Figure 9 Access to User Preferences

Figure 10 User Preferences Dialog

Figure 11 Change Password Popup


Pixel Core Integration Platform enables customization of many types used throughout of the system. Those dictionaries are configured via Types menu

Figure 12 Types Menu

Most of those configuration editors are visually the same so we will show only one editor

Figure 13 Contact Types


For stability and performance reasons, reporting is an external application that runs in separate VM (although it is possible to run it within the same servlet container).

Reports are based on JasperReports engine and could be prepared using JasperSoft Studio. Report is a ZIP package containing JRXML file(s) and all necessary resources, such as property bundles, images, Etc. It also must contain META-INF/MAINFEST.MF file with basic information about the report.

Report Editor

Reports are loaded and configured via Report Editor screen. Reporting engine could access multiple databases and hence each report requires mandatory JDBC connection URL and type. In many cases it is not possible to create a generic report that will properly render in PDF and XLSX formats, not to mention CSV or text. For that reason user must select what type of output format this report is intended to be rendered in.

Figure 14 Report Editor

After ZIP archive is loaded, it will be parsed by back-end and report parameters will be presented in Report Parameters tab. User can change default value and localized name of the parameter for future use in report browser or other parts of application.

Figure 15 Report Parameters

Report Browser

Although it is possible to use this screen as is in the final products, Report Browser is intended as an administrative screen, designed to test reports. It consists of tree like structure where first level is report type, second level is a report with output report type icons (PDF, XLSX, CSV, TXT, etc). By clicking on associated icon the report will be generated in that format and user will be presented with Save As dialog (if browser is configured to ask where to save downloaded files). The very last level is report parameters, which are used to populate parameter values.

Figure 16 Report Browser


As applications evolve and becomes ever more complex, having clear visibility of metric and event data to improve monitoring, troubleshooting and understanding is becoming even more crucial to ensure the performance of your app. Pixel Core Integration Platform enables control over what is being logged.

Various log levels could be assigned for specific packages and individual classes. If class or package under question is not available in the log list, it simply could be added through logging UI during runtime. Log levels also could easily be changed during run-time.

Figure 17 Logging

First column in the UI is an App name. Pixel Core Integration Platform supports distributed processing, where various components are running in separate VMs or could be geographically separated. Such component have their own codes and using centralized console logging levels could be change either globally or individually per specific remote component.

Application Preferences

Each application, no matter how small it is requiring some sort of configuration. Out of the box Pixel Core Integration Platform provides support for distributed configuration where the first column defines application code.

Figure 18 Application Preferences

Various aspects of application could be configured via this UI. Depending on implementation of components, in some cases changes in preferences could take effect immediately, but in another, application restart is required.

Multilingual Support

By design, Pixel Core Integration Platform provides for multi-lingual support on user interface level as well as on data level. Languages screen enables system administrators to specify which languages will application support.

Figure 19 Languages

Enabling specific language will make it available via Change Language menu

Figure 20 Change Active Language

Besides static interface localization, Pixel Core Integration Platform provides localization support for data object that could be configured in associated UI screens. It is important to note, that labels for default language are mandatory to enter. If selected language label is not found in the system it will be presented in default language.


In this case, we define Contact Type in two languages: English and French. Localization UI component enables to define label for specific data in all active languages.

Figure 21 Multi-lingual Configuration

Then in Client screen we can see how this type is presented when UI language changes. As it is clear to see not only interface labels and menus are changed language, but also user configured data is presented in selected language.

Figure 22 Localization Example – English Version

Figure 23 Localization Example – French Version


Large portion of Pixel Core Integration Platform functionality could be adjusted without need of programming, restarts or recompilation. Various components of the Platform use scripting support provided by the Platform out of the box.

Pixel Core Integration Platform provides support for following languages out of the box

  • JavaScript
  • SQL
  • Velocity
  • XML
  • Properties
  • Shell

After script is saved the type of the script cannot be changed.


Figure 24 Script Types

Velocity Templates

Platforms’ email notification system relies heavily on Velocity templates. There are number of predefined templates that must be present in the system for it to function properly:


Those templates are available out of the box and could be modified to fit specific client requirements.

Each email template consists of two parts

  • TEMPLATE_NAME – actual email body
  • TEMPLATE_NAME_SUBJ – email subject line

Each user has default language. If language is different from default (English), then it is possible to configure email system to send email notifications in users’ language. In that case template code must have two letter language code appended at the end.

  • TEMPLATE_NAME_FR – actual email body
  • TEMPLATE_NAME_SUBJ_FR – email subject line

Figure 25 Forgot Password Template Details

Figure 26 Forgot Password Template Content


Pixel Core Integration Platform provides an extensive support for scripting. Various components within the core system and in many derived systems are using scripting functionality to dynamically change components’ behavior.

JavaScript engine based on Java Nashorn implementation. While Nashorn is an ECMA-compliant implementation of the language, it is important to note that objects normally accessible in a web browser are not available in the back-end, for example, console, window, and so on. If the script is used on UI level full browser functionality is available for the script implementer.

One of big advantages of scripting approach is built-in support for Java components provided by Platform. Srcipts can access systems’ internal classes and methods the same way as they available to application developers via Java API.

Figure 27 JavaScript based Script


Pixel Core Integration Platform provides scheduled tasks execution support. Platform can automate jobs and run them at specific times.

Integration Platform comes with many tasks that could be used out of the box to automate commonly used functionality, such as sending password expiration notifications, generating and distributing reports, etc.

  • Database Script – execute an SQL script containing list of statements separated by semicolon
  • Ftp Loader – download specified file from remote server
  • Password Expiry Notification – notifies users whose password is about to expire (if configured)
  • Schedule Checker – check and reload schedules if modified outside of Platforms’ UI
  • Script Executor – execute JavaScript script

Figure 28 Scheduled Task

Different tasks have different parameters that dynamically changed in the UI on Class Name change.

Request for Call Back