Overview

The preloaded database is a performance optimization feature in Maximo Mobile that allows frequently-accessed, relatively static data to be pre-generated on the server and downloaded to mobile devices before synchronizing transactional data.

This approach significantly reduces the time required for initial data synchronization by separating static reference data (like lookup values, classifications, and item masters) from dynamic transactional data (like work orders and service requests).

Key Benefits

Faster initial sync times - Users download pre-generated data instead of querying and building it on-demand
Reduced server load - Static data is generated once and reused across multiple users
Improved user experience - Quicker onboarding for new users or devices
Efficient data distribution - Large reference datasets can be distributed without impacting sync performance

How It Works

Server-side Process:
1. Identify datasources marked with look-data="true"
2. Generate preloaded database file(s) based on partitioning strategy
3. Host preloaded database files on server

Mobile Sync Process:
1. User initiates sync
2. Device downloads appropriate preloaded database (based on partition)
3. Device then syncs transactional data

Purpose of the Preloaded Database

The preloaded database serves as a static data foundation that is downloaded before transactional data synchronization begins.

What Data Belongs in the Preloaded Database

Data that is ideal for preloading typically has these characteristics:

Infrequently changes - Reference data that remains stable over time
Shared across users - Data that many or all users need
Large volume - Datasets that would take significant time to sync individually
Read-mostly - Data that users consume but rarely modify

Common Examples

Typical data included in preloaded databases:

Lookup values - Domain values, synonyms, and classifications
Item masters - Tools, parts, and materials catalogs
Location hierarchies - Site structures and location trees
Asset classifications - Asset types and classification structures
Labor codes - Craft and skill definitions
Failure codes - Problem, cause, and remedy codes
Service address data - Customer locations and service territories

What Data Should NOT Be Preloaded

Data that should remain in transactional sync:

Work orders - Frequently changing, user-specific
Service requests - Dynamic, assignment-based
Inventory transactions - Real-time, transactional
Labor entries - User-specific, time-sensitive
Attachments - Large files, user-specific

Configuring Datasources for Preloading

Marking Datasources for Preload

To include a datasource in the preloaded database, add the look-data="true" attribute to the datasource definition in your mobile application XML.

Example:

<maximo-datasource
  id="itemDS"
  object-structure="MXAPIITEM"
  look-data="true">
  <schema>
    <attribute name="itemnum" searchable="true" id="attr_001"/>
    <attribute name="description" searchable="true" id="attr_002"/>
    <attribute name="itemtype" id="attr_003"/>
    <attribute name="status" id="attr_004"/>

Important Considerations

Field Selection:

Only include fields that are actually needed
Avoid selecting unnecessary fields that increase database size
Consider mobile device storage constraints

Query Optimization:

Use saved queries to filter data appropriately
Avoid overly broad queries that include unnecessary records
Balance completeness with performance

Related Data:

Consider which relationships need to be preloaded
Avoid deep relationship chains that bloat the database
Test the impact of related data on database size

Limitations of the Preloaded Database

Single Saved Query Limitation

Critical Limitation: When multiple datasources use the same object structure with look-data="true", only one saved query will be applied across all of them.

Example of the Problem

<!-- Datasource 1: Uses saved query "ACTIVE_ITEMS" -->
<maximo-datasource
  id="activeItemsDS"
  object-structure="MXAPIITEM"
  look-data="true"
  saved-query="ACTIVE_ITEMS">
  <!-- ... -->
</maximo-datasource>

Result: Only one of these saved queries (typically the first one processed) will be used to generate the preloaded database. The second query will be ignored.

Partitioning Strategies

Partitioning allows you to create multiple preloaded databases tailored to different user groups, reducing the amount of data each user needs to download.

Why Partition?

Benefits of Partitioning:

Reduced download size - Users only get data relevant to them
Faster sync times - Smaller databases download and process faster
Better performance - Less data to search and filter on device
Targeted data distribution - Different user groups get different data

When to Partition:

Data requirements vary significantly by user group
Database size is large enough to impact performance
Users are geographically distributed
Different sites or organizations have distinct data needs

Partition by Site ID

Partitioning by Site ID creates separate preloaded databases for each site, ensuring users only download data relevant to their location.

Use Cases:

Multi-site organizations with site-specific data
Geographically distributed operations
Sites with distinct item masters or asset catalogs
Regional compliance or language requirements

Configuration:

Refer to IBM documentation for detailed setup: Creating Preloaded Data for Mobile Using Site ID

Key Steps:

Enable site-based partitioning in Maximo configuration
Configure datasources with appropriate site filters
Generate preloaded databases for each site
Configure mobile app to request site-specific database

Example Scenario:

Organization with 3 sites:
- Site A (BOSTON): 5,000 items, 2,000 assets
- Site B (CHICAGO): 4,500 items, 1,800 assets  
- Site C (DENVER): 3,000 items, 1,500 assets

Without partitioning: Each user downloads 12,500 items, 5,300 assets
With site partitioning: Each user downloads only their site's data
- Boston users: 5,000 items, 2,000 assets (60% reduction)
- Chicago users: 4,500 items, 1,800 assets (64% reduction)

Partition by Person Group

Partitioning by Person Group creates preloaded databases based on user roles or organizational groups, allowing role-specific data distribution.

Use Cases:

Different crafts need different tool/part catalogs
Supervisors need broader data than technicians
Specialized teams work with distinct asset types
Role-based data access requirements

Configuration:

Refer to IBM documentation for detailed setup: Creating Preloaded Data for Mobile Using Person Group

Key Steps:

Define person groups in Maximo
Configure person group-based partitioning
Associate users with appropriate person groups
Generate preloaded databases for each person group
Configure mobile app to request group-specific database

Example Scenario:

Organization with 3 person groups:
- ELECTRICIANS: Need electrical items, tools, and codes
- PLUMBERS: Need plumbing items, tools, and codes
- HVAC: Need HVAC items, tools, and codes

Without partitioning: All users download all items (15,000 total)
With person group partitioning:
- Electricians: 5,000 relevant items (67% reduction)
- Plumbers: 4,000 relevant items (73% reduction)

Partition by Language

Partitioning by Language creates preloaded databases with language-specific translations, supporting multilingual deployments.

Use Cases:

Multinational organizations
Multilingual workforce
Regional language requirements
Compliance with local language regulations

Configuration:

Refer to IBM documentation for detailed setup: Creating Preloaded Data for Mobile Using Site ID and Language

Key Steps:

Configure language support in Maximo
Ensure translations exist for relevant data
Enable language-based partitioning
Generate preloaded databases for each language
Configure mobile app to request language-specific database

Example Scenario:

Organization supporting 3 languages:
- English (EN): 10,000 items with English descriptions
- Spanish (ES): 10,000 items with Spanish descriptions
- French (FR): 10,000 items with French descriptions

Without partitioning: Each user downloads all language variants
With language partitioning: Each user downloads only their language
- Reduces redundant translation data
- Improves search and display performance

Managing Preloaded Databases in Maximo

Configuration Application

Preloaded databases are managed through the Maximo Manage interface.

Access: Refer to IBM documentation for detailed management instructions: Configuring Preloaded Databases

Key Management Tasks

1. Generate Preloaded Databases

Trigger generation manually or on schedule
Monitor generation progress and status
Review generation logs for errors

2. Monitor Database Status

Check generation timestamps
Verify database sizes
Confirm partition coverage

3. Update Preloaded Data

Regenerate when source data changes significantly
Schedule regular regeneration (e.g., nightly, weekly)
Balance freshness with server load

4. Distribute to Devices

Ensure databases are accessible to mobile clients
Monitor download success rates
Troubleshoot download failures

5. Optimize Performance

Review database sizes and adjust queries
Analyze partition effectiveness
Refine datasource selections

Best Practices

✅ Do:

Regularly review and optimize preloaded datasources
Monitor preloaded database sizes and generation times
Test preloaded database downloads before deploying to users
Document your partitioning strategy and rationale
Schedule regeneration during off-peak hours
Keep preloaded data focused on truly static reference data

❌ Don’t:

Include transactional data in preloaded databases
Over-partition (too many small databases increases overhead)
Under-partition (databases too large for efficient download)
Forget to regenerate after significant data changes
Include unnecessary fields or relationships
Ignore storage constraints on mobile devices

Performance Considerations:

Larger preloaded databases take longer to download and process
More partitions increase server-side management overhead
Balance data completeness with download time
Consider network bandwidth in your deployment environment
Test with realistic data volumes

Maintenance Considerations:

Establish a regular regeneration schedule
Monitor for failed generations
Plan for data growth over time
Document partition assignments for users

Summary

The preloaded database is a powerful optimization feature that:

Improves sync performance by separating static reference data from transactional data
Reduces server load by pre-generating commonly-needed data
Enhances user experience with faster initial sync times

Key Points to Remember:

Mark datasources with look-data="true" to include them in the preloaded database
Only one saved query per object structure is supported across all preloaded datasources
Partition by Site ID, Person Group, or Language to reduce download sizes
Manage preloaded databases through the Maximo Manage interface
Balance data completeness with performance and storage constraints

Planning Checklist:

Identify which datasources contain static reference data
Determine appropriate partitioning strategy
Configure datasources with look-data attribute
Set up partitioning in Maximo
Generate and test preloaded databases
Monitor performance and adjust as needed
Establish regeneration schedule

By properly implementing and managing preloaded databases, you can significantly improve the mobile synchronization experience for your users while reducing server load and network bandwidth requirements.

Edit this page on GitHub

Basic concepts: Dialog Component Guide

Basic concepts: Data Sources Guide

Understanding the Preloaded Database

Overview

Key Benefits

How It Works

Purpose of the Preloaded Database

What Data Belongs in the Preloaded Database

Common Examples

What Data Should NOT Be Preloaded

Configuring Datasources for Preloading

Marking Datasources for Preload

Important Considerations

Limitations of the Preloaded Database

Single Saved Query Limitation

Example of the Problem

Partitioning Strategies

Why Partition?

Partition by Site ID

Partition by Person Group

Partition by Language

Managing Preloaded Databases in Maximo

Configuration Application

Key Management Tasks

Best Practices

Summary