Infor LN Batch Jobs Optimization Guide

Batch Job Architecture and Scheduling

LN batch jobs run through the session server infrastructure, executing Type 4 (processing) and Type 3 (report) sessions in background mode. Job scheduling uses the LN job scheduler or external schedulers like Control-M for enterprise orchestration. Design job chains with explicit dependencies: MRP must complete before planned order firming, cost calculations must precede financial posting, and master data synchronization must precede any dependent processing.

• Map all batch job dependencies and sequence them to prevent data staleness from out-of-order execution
• Use the LN job scheduler for LN-specific jobs and an enterprise scheduler for cross-system coordination
• Configure job-level timeouts based on historical execution times plus a growth buffer of 30-50%
• Implement job-level logging that records start time, end time, record counts, and error details for trending

MRP and Planning Job Optimization

MRP is typically the longest-running batch process in LN. Full MRP regeneration can take 4-12 hours in large environments. Optimize by maintaining clean planning data, removing obsolete items from planning, correcting lead times, and purging expired orders.

Use net change MRP for daily runs and reserve full regeneration for weekly maintenance. Partition MRP runs by planning cluster when possible to enable parallel processing.

• Run net change MRP daily and full regeneration weekly to balance planning accuracy with runtime
• Remove obsolete planning items, expired orders, and inactive items from the planning scope regularly
• Partition MRP by planning cluster or item group to enable parallel MRP processing where LN supports it
• Monitor MRP runtime trends and investigate increases exceeding 10% that suggest data quality degradation

Monitoring and Failure Recovery

Batch job failures at 3 AM should not be discovered at 8 AM. Implement proactive monitoring that detects failures within minutes and alerts the on-call team. Build automated recovery for common failures: deadlock retries, connection timeout restarts, and automatic job chain resumption from the failed step.

Every critical batch job should have a documented manual recovery procedure for cases where automation cannot resolve the issue.

• Configure email and SMS alerting for batch job failures with sufficient detail for remote diagnosis
• Implement automatic retry logic for transient failures: deadlocks, timeouts, and temporary resource locks
• Build checkpoint-restart capability into long-running jobs so failures resume from the last successful point
• Document manual recovery procedures for each critical batch job and test them during scheduled maintenance