Maximo Application Suite 8 support

Installation

Push Notification

User Authentication

Catalog Partitioning Strategies

Improved Queue Processor Configuration

Informer Queue Table Externalization

Enhanced Reconciliation UI

Catalog Partitioning feature

New Catalog Queue

New Catalog API

New API on the NOTIFYPUB service allowing public and anonymous access to designated commands and resources.

Performance improvements and bug fixes.

Maximo 7.6 support.

New multi-platform installer

Efficiency enhancements

Bugfixes

Catalog change evaluation architecture changed to use a queue instead of performing initial evaluation on background thread . This allows catalog evaluation processing to be isolated to one or more selected JVMs and prevents potential delays in processing if a large number of transactions are performed on a single JVM.

Full catalog data set now tracked . This allows for the forced reevaluation of all catalog records for active devices . The catalog can now be rebuilt in the case that data is loaded directly to the database or if the where clause includes date based parameters.

Added SQLite database generation for download to the device for preloaded catalogs. This allows supporting clients to download the database directly and skip the XML for the initial catalog load.

Added support for resources to be delivered to supporting clients . This allows images, documents, and other application resources to be provided to the application directly.

Changed catalog listeners to be explicitly defined, if upgrading from a previous release the current configuration will be automatically upgraded.

Added monitoring and tracking to allow for better record lifecycle tracking and queue performance monitoring.

Added version installation tracking in the ISNOTIFYVERSION table.

Bug fixes and enhancements.

Installers are available for both Windows and Linux/AIX. Windows installers have a .exe file extension, and Linux/AIX installers have a .run extension.

Informer Installers are available for Windows and Linux/AIX. Your choice of installer should be determined by the OS of the system containing your SMP folder, not by the OS on which WebSphere is running (if these are different systems).

The instructions and screenshots from here on will presume Windows by default, but should remain functionally applicable for all supported systems.

You will need:

Installer are available as Maximo Customization Archive

The installation procedure applies any pending database configuration changes. Therefore, please make sure that all pending database configuration changes have been applied prior to beginning the Release Manager or Informer installation process.

Verify that the entries in ALNDOMAIN with domain id DBSTORAGEPARTITION are correct for the Maximo environment, and that there are no extra entries. The Informer installation process will use these entries to identify the Maximo database schema.

Ensure that the Maximo property mxe.int.webappurl is a valid URL to access the Maximo application.

For Maximo 7.5.0.x, the Informer installer only supports automatic deployment to the Product Web Service Container. If you want the automatic web service deployment to occur the mxe.int.containerdeploy property must be set to 0 (zero).

The Informer installation assumes that a security group named EVERYONE exists for use in some required conditional expressions. If your system does not include this security group, add a new system property named informer.condexp.group and specify the global group that all users should be part of.

If the target environment has the Oil & Gas Industry Solution or the Health, Safety Environment Module installed it is necessary to check that each org-level object contains an associated ORGID attribute and each site-level object contains an associated SITEID attribute. Without these attributes, Maximo database configuration will fail and therefore the Informer installation will not complete.

ORGID attributes will need to be added for all objects returned from the following query:

SITEID attributes will need to be added for all objects returned from the following query:

The PMCOMSR Maximo Service has not existed since Maximo 7.1. The official Maximo 7.5 upgrade guide from IBM includes instructions to disable this Service during upgrade.

When this Service remains disabled, but not removed, the upgrade will be successful and database migration will be possible. As long as it exists, however, even when disabled, it will cause Maximo to fail validation whenever attempting to deploy any new "Standard Web Service" in Maximo. Informer defines such services as part of its installation process, so this Maximo issue must be fixed prior to Informer installation.

If this Service entry still exists in your Maximo 7.5+ instance, remove it entirely using the following SQL:

Not all upgrade paths can be anticipated or automatically corrected for, especially when old data/state is the product of bugs since fixed.

If upgrading, please also conduct the appropriate checks and precautions linked below, to help ensure a smooth upgrade.

Choose the most applicable document to match your current version:

At the time of this publication, the latest version of Informer was 6.0.0. This document presumes that the version being installed matches this version or later.

Binaries can be downloaded from our support site at https://support.interlocsolutions.com/projects/informer-server/files or may have been provided to you directly by an Interloc contact.

Informer and Push Relay are delivered in a single package to ensure that you always have compatible versions as a set.

Execute the informerserver-*.exe executable to start the installation, displaying the installation welcome screen.

Click the Next button to continue with the installation.

The license agreement is displayed for review and acceptance . Click the"I Agree" button to accept the license and then click Next to continue with the installation.

Select the target Maximo installation’s parent SMP folder . For example, if Maximo has been installed to C:\IBM\SMP\maximo the destination folder should be C:\IBM\SMP . The installer validates that you have selected a valid Maximo installation folder before allowing the installation process to proceed.

The installation is now ready to run . Click the Next button to commence the installation.

The installer extracts the installation files to the target environment.

When the installation is complete, the confirmation dialog is displayed . Click the Finish button to complete the installation.

Once the installer has completed, a script must be run to modify local XML.

Navigate to the <SMP>\maximo\tools\maximo subfolder of your IBM product installation folder. Enter informer-install.bat, and press Enter to execute the command.

Once informer-install.bat has completed, the necessary database changes must be applied. Still within the <SMP>\maximo\tools\maximo directory, enter updatedb.bat and press Enter to execute the command.

Rebuild and redeploy any and all maximo.ear files, as you would for any other system configuration change.

Start all JVMs in the Maximo system.

The next step is post-installation configuration.

The Informer platform is configured and administered via the Informer Developer and Informer Administration applications respectively within Maximo.

When the application is initially installed, no security groups have access to the application. An administrator needs to log in and grant access to the groups that should have access to the Informer application.

Once access has been granted, the Informer Developer and Informer Administration applications can be found on the Administration menu.

Informer introduces its own Cron Tasks, for automated maintenance of the Informer system. Some of them are automatically configured with default instances, and some are not.

Please review the Appendix: Informer Cron Tasks section of this guide. The purpose of each Cron is described, as are recommendations and requirements for instance configuration.

For the Crons configured with default instances (e.g. CatalogPreload), review their schedules to determine whether this is compatible with your system load needs.

For the Crons without default instances (e.g. SessionPurge), consider whether this Cron is desirable, and what parameters might be.

An exhaustive list of Informer properties is included in the Appendix: Maximo Properties section of this guide.

Most are highly conditional, applicable only in specific unusual cases. Some, far less so.

The following is a list of the most commonly relevant properties, which you could consider before considering installation complete.

Take note of which of these values are live-refreshable in Maximo; Most are.

Based on IBM recommended best practices it is recommended to create separate JVM clusters for UI, MIF, CRON, and BROS (Reports). It is recommended when deploying Informer to define a fifth type of JVM cluster, dedicated to queue processing and requests from mobile devices. The recommended cluster configuration is based on IBM Knowledge Center – Configuring clustered systems.

The configured Informer Authenticator should be switched from the default "MaximoAuthenticator" to the "LDAPAuthenticator". All other properties mentioned in this document are configuration parameters for this new authenticator.

The default LDAP Context implementation is provided by WebSphere. We recommend changing this to one provided by the JDK, instead.

The value of informer.security.ldap.authtype should always be simple; SASL is not supported in this implementation.

The informer.security.ldap.url property identifies the path to your LDAP server, including protocol and port number.

When authenticating via LDAP via the simple strategy, a (DN, password) pair is used. Maximo login uses a simple "loginid", however, not a DN, so it is typically necessary to run an LDAP search to find the user’s DN.

Some LDAP servers can be configured to allow unauthenticated searches of the directory. The LDAPAuthenticator does not currently support unauthenticated search. You can try to use the Method 3 defined below, if applicable, or else define a service account for use by Informer (even if this is not strictly necessary) for use in Method 1.

In the case that the loginid appears as part of the user DN, and all users to authenticate are siblings at the same level in the hierarchy, a DN pattern can be specified to skip the user lookup search entirely by transforming a loginid directly into a user DN.

The symbol {0} is once again used a placeholder for whatever loginid is being authenticated.

Push Relay installers are available for Windows and Linux, but can also be deployed manually to any compatible Servlet container that supports JAX-RS . The WAR file for deploying to a non-Windows environment can be obtained by running the installer then copying the push.war file found in the <push_home>\webapps\push.war in Windows, or /opt/pushrelay/informer/webapps/push.war in Linux or AIX.

The Informer Push Relay is distributed as part of the bundled Informer installation downloads. Install (or upgrade to) the version of the Push Relay which comes alongside the primary Informer installer. Informer installation bundles can be found on the downloads page for Informer: https://support.interlocsolutions.com/projects/informer-server/files

Installers are available for both Windows and Linux/AIX. Windows installers have a .exe file extension, and Linux/AIX installers have a .run extension. Choose the version which matches your target system. The instructions and screenshots from here on will presume Windows by default, but should remain functionally applicable for all supported systems.

Execute the push-relay-*.exe executable to start the installation.

Click the Next button on the welcome screen to continue with the installation.

Select an installation folder, or leave the default and click the Next button.

Click the Next button to commence the installation.

Click the Finish button to complete the installation.

To verify that the push relay was installed correctly, open your browser and navigate to http://<hostname>:8080/push/verify where <hostname> is the name of the server that the relay service was installed on.

If everything was successfully installed, a page should be displayed stating

Execute the utility specifying only the –host parameter. This will connect to the Informer service and display the Informer version number.

This check requires a profile to be created and a user given access to that profile.

For example, to verify a profile named INFORMERTESTING with a user name of wilson and a password of wilson:

Maximo data is generally long-lived and slow-moving. The Maximo data must always be recoverable, and backups are a necessary part of administration. Changes need to be captured and should be replayed into pre-production environments.

Informer queue data, by contrast, is generally short-lived and fast-moving. The data can be regenerated if lost, so backups and data migrations are unnecessary.

These Informer queue tables (and associated tables) are defined as MBOs, and these queue MBOs are used as the default queue persistence mechanism. This reduces the administrative overhead and simplifies the infrastructure considerations for many, and is a reasonable default. The downside of this default is that Informer queue tables are generally backed up and logged with the rest of the Maximo data, and this can become a burden for some customers.

By moving these queue tables to a different database instance, that instance can be selected, tuned, configured, and/or isolated to better suit their high-volatility use case (for example, by disabling backups).

Any of the following databases can be used for a standalone Informer queue schema:

The database type you choose does not need to match the database type you are using for Maximo.

The following System properties control Informer processing threads run and if so how many will run on a given node.

Cleans up outdated Catalog information. Informer may defer deletion of obsolete or orphaned Catalog-related records for reasons of responsiveness and daytime operational efficiency. This CronTask sweeps up at night.

This is the Catalog counterpart to NotificationCleanup.

The CatalogPreload CronTask will evaluate all available catalogs that are marked for preload and regenerate the preload pages for all catalogs that have exceeded the update threshold defined on the Catalog record.

This CronTask is deprecated, and should no longer be used. It has been superseded by the CatalogCleanup CronTask.

This CronTask is deprecated, and should no longer be used. It has been superseded by the ReconcileCatalog CronTask.

Informer retains a set of information on each Command executed, including a hash of the request, and the response to deliver. These records allow the server to:

Although this information is very useful, over time this can become a significant number of records with diminishing value. The command history purge CronTask provides a mechanism to purge historical command information that has exceeded a specified retention period.

This CronTask cleans up expired Device registrations.

Informer will keep track of certain information about every Device which synchronizes with it. Should a device become unused, replaced, reset, etc, then Informer will never hear from that device again, yet is still retaining information about that device indefinitely. This CronTask cleans up those obsolete records.

For devices which have not logged in for a certain number of days, all device-related Information is cleared.

One of the data points that Informer tracks for each device is which Catalogs they have synchronized, and how up-to-date the device’s copy of that Catalog is. Legacy Catalog APIs (driven by Informer client version in the app) use this information to determine what to delivery to the devices. Should a device be "too far behind" in is synchronization of a large, fast-moving Catalog, then that registration will be reset, causing that particular device to leverage preloads to synchronize that particular Catalog upon next login.

The Catalog delta-counting cleanup is a more constrained cleanup for those records which out outdated for one or more Catalogs, yet have still been active within the configured timeout period (e.g. The device’s user goes on vacation for 2 weeks). This is especially important when using the legacy Catalog APIs, still used by some Informer clients at time of this writing.

When Informer Monitor threads run, they report the status of the processes they are monitoring to the database for display across JVMs in the system.

If a JVM goes down and does not return, this Cron ensures that stale data does not linger.

When Informer statistics tracking is enabled via system properties, data is collected as the system runs, but is not compiled into reports for human consumption. The InformerStats CronTask serves this purpose at regular intervals. Whenever this task is run, statistics are compiled from recent logged events, and the new report is saved as its own compiled record.

A lot of raw performance data is generated as the system runs, primarily for this CronTask to evaluate and compile. It is therefore the responsibility of this task to also clean up uncompiled records which have outlived their usefulness.

Cleans up outdated Notification information. Informer may defer deletion of obsolete or orphaned Notification-related records for reasons of responsiveness and daytime operational efficiency. This CronTask sweeps up at night.

This is the Notification counterpart to CatalogCleanup.

This CronTask will trigger a reconciliation of the specified Catalogs whenever it is executed.

This can be used for eventual recognition of objects which do not reliably fire MBO events, or for Catalogs with "sliding window"(date-based) selection criteria in their where-clauses.

Forces a periodic reconciliation of the catalog content with the current result set as defined by the where clause.

Informer creates and manages its own session tokens for devices logging in through its API. This CronTask runs frequently, cleaning up state information for expired Sessions, which no longer require it.

The activities of this CronTask do NOT affect when Sessions become invalid, instead only conducting cleanup of the Sessions which have already expired.

Note that this CronTask does not remove records from the more permanent, less stateful ISSESSIONHISTORY table. See SessionPurge.

The Informer platform indefinitely retains session history information for each session that is created by a client device. This information is very useful when attempting to diagnose connectivity issues or analyze usage patterns. However, over time this can become a significant number of records with diminishing value. The SessionPurge purge CronTask provides a mechanism to purge historical session information that has exceeded a specified retention period.

The installer attempts to establish a connection to the specified database and then inserts new records in the MAXSERVICE table with the following values:

In addition to the database entries the installer also adds a Servlet entry to the <maximo_home>\applications\maximo\maximouiweb\webmodule\WEB-INF\web.xml and updates the <maximo_home>\applications\maximo\meaweb\webmodule\WEB-INF\web.xml with a comment that can removed to ensure that the NOTIFYINFO service is left unauthenticated in a secured environment.

The <maximo_home>\applications\maximo\maximouiweb\webmodule\WEB-INF\web.xml file has the following entries added:

and

Installing the Interloc Mobile Informer to the target Maximo installation folder also adds a product.xml file named isinformer.xml to the <maximo_home>\deployment\product folder. This file ensures that the Java JAR files required by the installer are included in the Maximo class path.

When upgrading to Informer 5.x from 4.x, there are duplicate MAXMENU entries. Run the following SQL statement before upgrading:

This will resolve the issue.

If upgrading a system which has an existing Informer installation of 5.2 or earlier, please perform the following steps:

In versions of Informer before 5.5.0, it was possible to have multiple identical Catalog registrations (for the same device registering for the same revision of the same Catalog), due to timing issues. This resulted in lookup errors, causing affected devices to get inaccurate or missing prompts for Catalog synchronization. A unique index now prevents this possibility, and is installed with Informer. In order for installation to succeed, the current data must not violate this new unique index.

This SQL will have no effect if nothing needs to be corrected. There is no need to run this again during subsequent upgrades.

Run the following SQL while the system is down, before upgrading:

In versions of Informer before 5.4.0, it was possible to have multiple functionally-identical records in ISCATALOGDATA, which could result in lookup errors. A unique index now prevents this possibility, and is installed with Informer. In order for installation to succeed, the current data must not violate this new unique index.

This SQL will have no effect if nothing needs to be corrected. There is no need to run this again during subsequent upgrades.

Run the following SQL while the system is down, before upgrading:

In versions of Informer before 5.3.0, some fields were functionally required, but not enforced in the database configuration. Running these two queries corrects the record, preventing errors during upgrade without sacrificing other forms of validation.

In versions of Informer before 5.5.0, it was possible to have multiple identical Catalog registrations (for the same device registering for the same revision of the same Catalog), due to timing issues. This resulted in lookup errors, causing affected devices to get inaccurate or missing prompts for Catalog synchronization. A unique index now prevents this possibility, and is installed with Informer. In order for installation to succeed, the current data must not violate this new unique index.

This SQL will have no effect if nothing needs to be corrected. There is no need to run this again during subsequent upgrades.

Run the following SQL while the system is down, before upgrading:

If upgrading a system which has an existing Informer installation of 5.2 or earlier, please perform the following steps:

In versions of Informer before 5.5.0, it was possible to have multiple identical Catalog registrations (for the same device registering for the same revision of the same Catalog), due to timing issues. This resulted in lookup errors, causing affected devices to get inaccurate or missing prompts for Catalog synchronization. A unique index now prevents this possibility, and is installed with Informer. In order for installation to succeed, the current data must not violate this new unique index.

This SQL will have no effect if nothing needs to be corrected. There is no need to run this again during subsequent upgrades.

Run the following SQL while the system is down, before upgrading:

In versions of Informer before 5.4.0, it was possible to have multiple functionally identical records in ISCATALOGDATA, which could result in lookup errors. A unique index now prevents this possibility, and is installed with Informer. In order for installation to succeed, the current data must not violate this new unique index.

This SQL will have no effect if nothing needs to be corrected. There is no need to run this again during subsequent upgrades.

Run the following SQL while the system is down, before upgrading:

In versions of Informer before 5.3.0, some fields were functionally required, but not enforced in the database configuration. Running these two queries corrects the record, preventing errors during upgrade without sacrificing other forms of validation.

In versions of Informer before 5.5.0, it was possible to have multiple identical Catalog registrations (for the same device registering for the same revision of the same Catalog), due to timing issues. This resulted in lookup errors, causing affected devices to get inaccurate or missing prompts for Catalog synchronization. A unique index now prevents this possibility, and is installed with Informer. In order for installation to succeed, the current data must not violate this new unique index.

This SQL will have no effect if nothing needs to be corrected. There is no need to run this again during subsequent upgrades.

Run the following SQL while the system is down, before upgrading:

In versions of Informer before 5.4.0, it was possible to have multiple functionally identical records in ISCATALOGDATA, which could result in lookup errors. A unique index now prevents this possibility, and is installed with Informer. In order for installation to succeed, the current data must not violate this new unique index.

This SQL will have no effect if nothing needs to be corrected. There is no need to run this again during subsequent upgrades.

Run the following SQL while the system is down, before upgrading:

In versions of Informer before 5.3.0, some fields were functionally required, but not enforced in the database configuration. Running these two queries corrects the record, preventing errors during upgrade without sacrificing other forms of validation.

In versions of Informer before 5.5.0, it was possible to have multiple identical Catalog registrations (for the same device registering for the same revision of the same Catalog), due to timing issues. This resulted in lookup errors, causing affected devices to get inaccurate or missing prompts for Catalog synchronization. A unique index now prevents this possibility, and is installed with Informer. In order for installation to succeed, the current data must not violate this new unique index.

This SQL will have no effect if nothing needs to be corrected. There is no need to run this again during subsequent upgrades.

Run the following SQL while the system is down, before upgrading:

In versions of Informer before 5.5.0, it was possible to have multiple identical Catalog registrations (for the same device registering for the same revision of the same Catalog), due to timing issues. This resulted in lookup errors, causing affected devices to get inaccurate or missing prompts for Catalog synchronization. A unique index now prevents this possibility, and is installed with Informer. In order for installation to succeed, the current data must not violate this new unique index.

This SQL will have no effect if nothing needs to be corrected. There is no need to run this again during subsequent upgrades.

Run the following SQL while the system is down, before upgrading:

To use the old notification queue processor, set the Maximo property informer.notification.queue.QueueProcessor to com.interlocsolutions.maximo.notify.queue.notification.BulkByThreadNotificationJobQueueProcessor.

The informer.queue.pool.notification property is specified as a comma-separated string of the form "x,y,z", where x represents the number of "User Expansion" processors, y represents the number of "User Evaluator" processors, and z represents the number of "Record" processors.

The "User Expansion" pool is important, but more than 1 is not necessary. When scaling up, the most effective balance of "User Evaluation" vs "Record" processors depends on your Profile, users, and environment. Generally speaking, if you have many users with few records on average, then increasing "User Evaluation" processors will help more, and if you have fewer users with more records on average, then increasing "Record" processors will help more.

To use the old catalog queue processor, set the Maximo property informer.catalog.queue.QueueProcessor to com.interlocsolutions.maximo.notify.queue.db.BulkByThreadCatalogJobQueueProcessor.

The informer.queue.pool.catalog property is specified as a comma-separated string of the form "x,y", where x represents the number of "Aggregate" processors, and y represents the number of "Record" processors.

"Record" processors should always be significantly more numerous than "Aggregate" processors. When scaling up the processor pool, a ratio of about 1-to-10 is a reasonable place to start.

To use the old push queue processor, set the Maximo property informer.push.queue.QueueProcessor to com.interlocsolutions.maximo.notify.push.BulkByThreadPushJobQueueProcessor.

The informer.queue.pool.push property is specified as a single numeric value. If using a Push configuration, set this value to 1 on at least one JVM. If you are certain you will not use Push, you can disable this globally by setting a value of 0.