MAS - Creating and configuring API keys for push notifications

Push notifications in IBM Maximo Application Suite (MAS) Manage allow field technicians and users to receive real-time alerts on their mobile devices — without having to manually refresh or stay logged in. Before any notification can be delivered, you need to generate an API Key from IBM's Push Notification service and then configure it inside MAS Administration. This article walks you through every step with full explanation of what each setting does and why it matters.

💡 Who needs this? MAS Administrators setting up mobile push notifications for Maximo Manage users on iOS or Android devices. This is a one-time setup per MAS environment (DEV / TEST / PROD each need their own API Key).

🔔 What Are Push Notifications in MAS Manage?

MAS Manage supports sending push notifications directly to users' mobile devices via the IBM MAS Mobile app. These can include workflow approvals, assignment alerts, work order updates, and service request status changes. The mechanism relies on IBM's hosted Push Notification service, which acts as the delivery bridge between MAS and the device.

The integration requires two things to be in place:

1. An API Key generated from the IBM Push Notification portal, which authorises MAS to send messages via the service.
2. The API Key and endpoint URL configured inside MAS Administration so the platform knows where and how to route notification requests.

⚠️ Upgrading from a Previous Version?
If you are upgrading from an older version of Maximo Manage, you may have a saved (bookmarked) URL that is no longer valid. Always double-check any previously saved portal URLs before following the steps below — IBM may have updated the endpoint.

🔑 Part 1 — Generating the API Key

The first part of the process is performed outside of MAS, directly on IBM's Push Notification portal. You will need a valid IBM ID to authenticate.

Step 1 — Open the Push Notification Portal

Open a browser and navigate to the IBM Push Notification authentication page:

https://pushnotification.suite.maximo.com/pushnotification/auth

📌 Tip: Use a browser that is not behind a strict corporate proxy for this step. Some enterprise proxies block external IBM portal traffic. If the page doesn't load, try from an alternate network or raise it with your network team.

Step 2 — Sign In with IBM ID

On the portal page, click "Sign in or up". You will be redirected to IBM's identity provider (IBMid). Log in using your registered IBM ID credentials. If you don't have one, you can register for free at ibm.com.

Step 3 — Create and Generate the API Key

Once authenticated:

1. Enter a meaningful name for your API Key (e.g., MAS-PROD-PushNotif or MAS-TEST-PushNotif). Using environment-specific names makes key management easier if you're running multiple MAS instances.
2. Click "Generate API Key".
3. The portal will display the generated API Key value. Copy this immediately — the key will not be shown again once you leave the page.

⚠️ Important: Store the copied API Key securely (e.g., in a password manager or your organisation's secrets vault). If you lose it, you will need to generate a new one and reconfigure MAS.

⚙️ Part 2 — Configuring the API Key in MAS Administration

With the API Key copied, switch over to your MAS environment to complete the configuration.

Step 1 — Log in to Maximo Application Suite

Log in to your MAS environment with an account that has Suite Administration privileges.

Step 2 — Navigate to Push Notification Settings

1. Click the Administration icon (the gear/cog icon) from the MAS home screen.
2. Select Configurations from the left-hand navigation.
3. Under the "Users and identity" section, click "Push Notification".

Step 3 — Enter the Push Notification Configuration

Click "Edit" and populate the three fields as follows:

Field	Value to Enter	Notes
Bundle Identifier	com.ibm.iot.maximo.mobile	This is the iOS/Android app bundle ID for the IBM MAS Mobile app. Do not change this value.
URL	https://pushnotification.suite.maximo.com/pushnotification/sendMessage	IBM's hosted push notification delivery endpoint. This is the URL MAS will POST messages to.
API Key	Your generated API Key value	Paste the key you copied from the IBM Push Notification portal in Part 1.

Step 4 — Save the Configuration

Click "OK" to save the configuration. MAS will now use these credentials to dispatch push notifications to mobile users.

✅ Tip: After saving, ask a test user to log in via the MAS Mobile app and trigger a notification (e.g., a workflow assignment). Verify that the notification arrives on their device within a few seconds to confirm the integration is working end-to-end.

📋 Quick Reference Summary

Activity	Where	Who
Generate API Key	pushnotification.suite.maximo.com	IBM ID account holder
Configure Push Notification	MAS Admin → Configurations → Users & Identity	MAS Suite Administrator
Bundle Identifier	com.ibm.iot.maximo.mobile	Fixed value — do not change
Push URL	pushnotification.suite.maximo.com/pushnotification/sendMessage	IBM hosted endpoint

🔍 Things to Watch Out For

API Key Rotation: IBM does not enforce automatic expiry on these keys, but it is good security practice to rotate them periodically (e.g., annually) or immediately after a staff change where someone who held the key leaves the organisation. After rotation, you must update the API Key in MAS Administration.

Multiple Environments: If you run separate DEV, TEST, and PROD MAS environments, generate a separate API Key for each. This ensures notifications from a test environment don't inadvertently route through your production key.

Firewall / Outbound Connectivity: MAS needs outbound HTTPS access to pushnotification.suite.maximo.com on port 443. Ensure your MAS Manage pods / nodes are not blocked by network policies or firewall rules from reaching this endpoint.

Mobile App Version: Ensure your users have a version of the IBM MAS Mobile app that supports push notifications for your version of MAS Manage. Older app versions on older MAS releases may not fully support the push service.

📖 Official IBM Documentation: This article is based on the IBM Maximo Application Suite documentation for Maximo Manage (Continuous Delivery). For the latest updates, always refer to the official IBM Docs page:
IBM Docs – Creating and configuring API keys for push notifications

MAS : Estimating MAS AppPoints Using current Maximo 7.6 DB2 – A Complete SQL-Based Approach

Migrating from IBM Maximo Asset Management 7.6 to IBM Maximo Application Suite (MAS) requires a clear understanding of AppPoints, user persona classification, and peak concurrency. Many organizations struggle with this during modernization because licensing depends not only on the number of Maximo users, but also on: Peak concurrent usage User security profiles Installed Industry Solutions / Add-ons Required personas (Admin, Practitioner, Viewer) A reasonable buffer to avoid under-licensing This article simplifies the entire approach by providing a ready-to-run SQL script for DB2, which analyzes your Maximo 7.6 environment and produces: ✔ Peak concurrent users ✔ User-type suggestion ✔ AppPoints estimate ✔ AppPoints with 25% buffer ✔ Impact of Industry/Add-on Solutions (Transportation, SP, HSE, O&G, BIM, etc.) 💡 Why You Should Calculate AppPoints From Actual Maximo Usage IBM recommends sizing MAS AppPoints based on real historical data, not just user list counts. Relying on license seats or security groups often leads to: Overestimation → unnecessary licensing cost Underestimation → compliance risk during audits Incorrect persona mapping → Admins vs Practitioners vs Viewers not understood This SQL solves these problems by: Measuring actual concurrency using LOGINTRACKING Understanding what applications users really access Mapping them automatically into user personas Applying dynamic add‑on multipliers based on installed Industry Solutions 📌 Full DB2 SQL – MAS AppPoints Estimator for Maximo 7.6 Copy and paste directly into DB2 or Maximo Report/DB tool. -- ============================================ -- Maximo 7.6 (DB2) → MAS AppPoints Estimator -- ============================================ WITH CONFIG_PERIOD AS ( SELECT CURRENT TIMESTAMP - 90 DAYS AS START_TS, CURRENT TIMESTAMP AS END_TS FROM SYSIBM.SYSDUMMY1 ), CONFIG_USER_POINTS AS ( SELECT 'ADMIN' AS USER_TYPE, 10 AS POINTS_PER_USER FROM SYSIBM.SYSDUMMY1 UNION ALL SELECT 'PRACTITIONER', 5 UNION ALL SELECT 'VIEWER', 1 ), TXN_APPS AS ( SELECT 'WOTRACK' AS APP FROM SYSIBM.SYSDUMMY1 UNION ALL SELECT 'ASSET' UNION ALL SELECT 'INVENTOR' UNION ALL SELECT 'INVUSE' UNION ALL SELECT 'PO' UNION ALL SELECT 'PR' UNION ALL SELECT 'MR' UNION ALL SELECT 'LABREP' UNION ALL SELECT 'SR' ), HOURS_SERIES (TS) AS ( SELECT START_TS FROM CONFIG_PERIOD UNION ALL SELECT TS + 1 HOUR FROM HOURS_SERIES, CONFIG_PERIOD WHERE TS + 1 HOUR <= (SELECT END_TS FROM CONFIG_PERIOD) ), SESSIONS AS ( SELECT LT.USERID, LT.LOGINTIME AS LOGIN_TS, COALESCE(LT.LOGOUTTIME, CURRENT TIMESTAMP) AS LOGOUT_TS FROM LOGINTRACKING LT JOIN CONFIG_PERIOD P ON LT.LOGINTIME BETWEEN P.START_TS AND P.END_TS WHERE LT.ATTEMPTRESULT = 'SUCCESS' ), CONC_BY_HOUR AS ( SELECT H.TS AS HOUR_TS, COUNT(DISTINCT S.USERID) AS CONCURRENT_USERS FROM HOURS_SERIES H JOIN SESSIONS S ON S.LOGIN_TS <= H.TS + 1 HOUR AND S.LOGOUT_TS > H.TS GROUP BY H.TS ), PEAK_CONC AS ( SELECT COALESCE(MAX(CONCURRENT_USERS), 0) AS PEAK_CONCURRENT FROM CONC_BY_HOUR ), ACTIVE_USERS AS ( SELECT DISTINCT MU.USERID FROM MAXUSER MU WHERE MU.STATUS = 'ACTIVE' AND COALESCE(MU.LOGIN, 1) = 1 AND MU.USERID NOT IN ('MAXADMIN','MXINTADM','MXINTSYS','SPDEMO','WILSON') ), USER_GROUPS AS ( SELECT DISTINCT AU.USERID, GU.GROUPNAME FROM ACTIVE_USERS AU JOIN GROUPUSER GU ON AU.USERID = GU.USERID ), ADMINS AS ( SELECT DISTINCT USERID FROM USER_GROUPS WHERE UPPER(GROUPNAME) = 'MAXADMIN' ), GRP_HAS_TXN AS ( SELECT DISTINCT AA.GROUPNAME FROM APPLICATIONAUTH AA WHERE AA.APP IN (SELECT APP FROM TXN_APPS) ), PRACT_USERS AS ( SELECT DISTINCT UG.USERID FROM USER_GROUPS UG WHERE UG.GROUPNAME IN (SELECT GROUPNAME FROM GRP_HAS_TXN) ), USER_ROLES AS ( SELECT U.USERID, CASE WHEN EXISTS (SELECT 1 FROM ADMINS A WHERE A.USERID = U.USERID) THEN 'ADMIN' WHEN EXISTS (SELECT 1 FROM PRACT_USERS P WHERE P.USERID = U.USERID) THEN 'PRACTITIONER' ELSE 'VIEWER' END AS USER_TYPE FROM ACTIVE_USERS U ), TYPE_TOTALS AS ( SELECT USER_TYPE, COUNT(*) AS TOTAL_USERS FROM USER_ROLES GROUP BY USER_TYPE ), ALLOC_CONC AS ( SELECT T.USER_TYPE, T.TOTAL_USERS, (SELECT PEAK_CONCURRENT FROM PEAK_CONC) AS PEAK_CONCURRENT, DECIMAL( (T.TOTAL_USERS * 1.0) / NULLIF(SUM(T.TOTAL_USERS) OVER (), 0) * (SELECT PEAK_CONCURRENT FROM PEAK_CONC), 18, 4 ) AS CONCURRENT_EST FROM TYPE_TOTALS T ), ALLOC_CONC_R AS ( SELECT USER_TYPE, TOTAL_USERS, INTEGER(CEIL(CONCURRENT_EST)) AS CONCURRENT_USERS FROM ALLOC_CONC ), ADDON_MULTS AS ( SELECT 'MANAGE_CORE' AS ADDON, 1.00 AS MULTIPLIER FROM SYSIBM.SYSDUMMY1 UNION ALL SELECT 'SERVICE_PROVIDER', 1.15 WHERE EXISTS (SELECT 1 FROM MAXAPPS WHERE APP LIKE 'SP%') UNION ALL SELECT 'TRANSPORTATION', 1.10 WHERE EXISTS (SELECT 1 FROM MAXAPPS WHERE APP LIKE 'TR%') UNION ALL SELECT 'OIL_GAS', 1.10 WHERE EXISTS (SELECT 1 FROM MAXAPPS WHERE APP LIKE 'OIL%') UNION ALL SELECT 'HSE', 1.10 WHERE EXISTS (SELECT 1 FROM MAXAPPS WHERE APP LIKE 'HSE%') UNION ALL SELECT 'BIM', 1.05 WHERE EXISTS (SELECT 1 FROM MAXAPPS WHERE APP LIKE 'BIM%') ), PRODUCT_MULT AS ( SELECT MAX(MULTIPLIER) AS MULTIPLIER FROM ADDON_MULTS ), POINTS_BASE AS ( SELECT A.USER_TYPE, A.TOTAL_USERS, A.CONCURRENT_USERS, CUP.POINTS_PER_USER, (A.CONCURRENT_USERS * CUP.POINTS_PER_USER) AS BASE_POINTS FROM ALLOC_CONC_R A JOIN CONFIG_USER_POINTS CUP ON CUP.USER_TYPE = A.USER_TYPE ), POINTS_FINAL AS ( SELECT PB.USER_TYPE, PB.TOTAL_USERS, PB.CONCURRENT_USERS, INTEGER(CEIL(PB.BASE_POINTS * (SELECT MULTIPLIER FROM PRODUCT_MULT))) AS APP_POINTS, INTEGER(CEIL(PB.BASE_POINTS * (SELECT MULTIPLIER FROM PRODUCT_MULT) * 1.25)) AS APP_POINTS_WITH_25PC_BUFFER FROM POINTS_BASE PB ) SELECT PB.USER_TYPE, PB.TOTAL_USERS, PB.CONCURRENT_USERS, PB.APP_POINTS, PB.APP_POINTS_WITH_25PC_BUFFER FROM POINTS_FINAL PB UNION ALL SELECT 'TOTAL' AS USER_TYPE, SUM(PB.TOTAL_USERS), SUM(PB.CONCURRENT_USERS), SUM(PB.APP_POINTS), SUM(PB.APP_POINTS_WITH_25PC_BUFFER) FROM POINTS_FINAL PB WITH UR; 🔍 What This SQL Tells You 1. Peak Concurrent Users (PCU)Based on real login sessions from LOGINTRACKING. 2. Automatic Persona Mapping Admin → MAXADMIN or equivalent Practitioner → users with access to Work, Asset, Inventory, Purchasing Viewer → everyone else 3. Add-on/Industry Solution Detection The SQL automatically checks for: Service Provider Transportation Oil & Gas HSE BIM …and applies safe multipliers. 4. AppPoints Estimation With 25% Buffer Output includes: User TypeTotal UsersConcurrent UsersAppPointsAppPoints + 25% …plus a TOTAL row. 🚀 How to Use This as Part of MAS Upgrade Planning Step 1 — Run SQL in Maximo 7.6 Use DBViewer, DBeaver, or even BIRT query viewer. Step 2 — Review Persona Distribution Identify if too many users have practitioner-level access. Step 3 — Optimize Groups Before Migrating This is where MAS savings usually come from. Step 4 — Validate Peak Concurrency Confirm PCU with business teams. Step 5 — Size MAS AppPoints Correctly Use IBM’s MAS licensing matrix with SQL output. This SQL method gives organizations a data-driven, defendable, audit-ready way to size MAS AppPoints. It avoids guesswork, provides clarity to procurement teams, and supports architecture decisions during MAS migration.

MAS : Everything You Need to Know About Attachments Configuration in MAS Using S3 Block Storage

Maximo’s attachment architecture has evolved significantly in MAS, and S3‑compatible object storage is now the recommended pattern for storing attached documents. This article walks through the key concepts, required system properties, setup steps, and migration considerations when moving from traditional NFS/file‑based storage to S3.

---

Why Use S3 for Attachments?

S3‑style object storage offers several advantages over local NFS or file‑system‑based attachment storage:

• Scalability: You can grow storage without worrying about local disk limits.​

• Cost‑effectiveness: Pay‑as‑you‑go models reduce upfront hardware costs.​

• Resilience and availability: Cloud‑provider S3 or self‑hosted MinIO can provide redundancy and high availability.

• Simpler MAS upgrades: Using S3 from the start reduces post‑upgrade storage‑migration work.

In MAS, attachments are stored in an S3 bucket via the COSAttachmentStorage provider, which is also used in Maximo Manage 7.6.1.1+ and MAS‑based deployments.

---

Core S3 System Properties in Maximo / MAS

To route attachments to S3, you must configure a small set of system properties in the System Properties application.

Property	Purpose / Value
mxe.cosaccesskey	S3 access key (HMAC or IAM‑style) from your COS/S3 provider.
mxe.cossecretkey	S3 secret key (HMAC or IAM‑style).
mxe.cosendpointuri	Regional endpoint URI (e.g., https://s3.<region>.cloud-object-storage.appdomain.cloud for IBM COS).
mxe.cosbucketname	Name of the S3 bucket where attachments will be stored (e.g., maximo-doclinks).
mxe.attachmentstorage	Always set to com.ibm.tivoli.maximo.oslc.provider.COSAttachmentStorage.
mxe.doclink.securedAttachment	Set to true to hide raw file paths and encrypt attachment URLs.
mxe.doclink.doctypes.defpath	Always cos:DOCLINKS\\default for S3.
mxe.doclink.doctypes.topLevelPaths	Always cos:DOCLINKS for S3.
mxe.doclink.path01	Always cos:DOCLINKS=default for S3.

After setting these, restart the Server(s) so Maximo starts writing new attachments directly to S3.

---

Setting Up S3 / IBM Cloud Object Storage

For IBM Cloud Object Storage (COS), the typical flow is:​

1. In IBM Cloud, create an Object Storage resource (Standard plan).

2. Create a bucket with a unique name, region, and storage class (e.g., Smart Tier).

3. Generate Service Credentials with role Writer and enable HMAC credentials.

4. From the COS UI, obtain:

   • access_key_id and secret_access_key (HMAC).

   • The regional endpoint URI (public HTTPS URL).

You can reuse the same COS instance across multiple MAS/Maximo environments by creating separate buckets per environment (DEV/QA/PROD).​

The same pattern applies to Amazon S3 or MinIO‑compatible S3‑style storage; you just plug in the corresponding access key, secret, endpoint, and bucket name.

---

Migrating from NFS/File‑Based Storage to S3

If you are upgrading from an on‑prem EAM instance using NFS‑based attachments, you must migrate existing files to S3 and update Maximo’s pointers.

Step 1: Prepare the S3 bucket

• Create a bucket (e.g., maximo-doclinks) in your S3 provider.​

• Ensure Maximo’s S3 credentials have write access to that bucket.​

Step 2: Copy files from NFS to S3

On a machine that can access the NFS mount (or directly on the Maximo app server), use the AWS CLI or similar tool:​

bash
aws configure
# Enter accessKey and secretKey when prompted

aws s3 cp /nfs_path s3://maximo-doclinks/ \
  --endpoint-url http://<minio-host>:9000 \
  --recursive

For MinIO or other S3‑compatible endpoints, include --endpoint-url. You can also use aws s3 sync or tools like rclone for incremental or large‑scale migrations.​

Step 3: Update MAXIMO.DOCINFO URLs

Once files are in S3, you must change the URL prefix in the MAXIMO.DOCINFO table so Maximo points to the S3‑hosted files instead of the old NFS path.​

A typical pattern is to update the URLNAME field from something like:

sql
UPDATE MAXIMO.DOCINFO
SET URLNAME = REPLACE(URLNAME, '/nfs_path/', 'cos:DOCLINKS/')
WHERE URLNAME LIKE '/nfs_path/%';

Exact SQL depends on your schema and current URL pattern; always test in a non‑production environment first.​

---

Important S3‑Attachment Gotchas

• No subdirectories in S3 for new uploads: Maximo’s S3 implementation expects all attachment files at the root of the bucket; subfolders are ignored for new uploads.

• Folder structure in Manage is cosmetic: Manage’s “Folders” UI does not map to physical S3 folders; the system still looks for files at the top level.​

• Migration tooling in MAS: Maximo Manage ships with a file2s3.sh utility that can help convert file‑based attachments to S3, especially useful during MAS upgrades.