News, Events and Articles
You are here: / News, Events and Articles

Composable ERP: Architectural Reality or Executive Imperative?

ERP (enterprise resource planning) strategy is changing as businesses face growing pressure to adapt to shifting markets, new technologies, and increasing complexity. In an article by Sanjay Vijay Mhaskey for ERP Today, the focus is on whether composable ERP is a real-world approach or just a future vision—and the answer is both.

Composable ERP refers to an approach where an ERP system is built from flexible, interchangeable components instead of one large, all-in-one platform. This allows businesses to add, replace, or upgrade specific parts of their system without disrupting the whole. Traditionally, ERP systems were designed for stability, with long rollout cycles and heavy customization. But today, companies need more flexibility. Composable ERP offers a way to modernize step by step by adding new tools and capabilities rather than replacing the entire system. Many organizations are already doing this in practice. They connect new applications through APIs, upgrade specific modules, and add cloud or AI tools alongside their existing systems. This enables innovation without interrupting core operations. The biggest challenge isn’t the technology—it’s managing it all effectively. Clear rules for data, integrations, and security are essential. Without them, systems can become more complex instead of more flexible.

In the end, composable ERP is not a one-time change but a gradual process. Businesses that take a thoughtful, step-by-step approach can stay agile while maintaining a stable core system.

 

For Full Article, Click Here

How to resolve Lawson ‘Distribution List Has Not Been Defined’ Error in jobdef

, ,

Summary: When setting up a Distribution group so other users can view the print manager of another user, typically a system user like lawson. You need to complete a very important step before being able to add it.

 

  1. In Jobdef when you try and set the distribution group you get the “Distribution List Has Not Been Defined” error (not displayed below, but it’s an example of it being set)
  2. To resolve, go to users environment info shown below in ISS (This can be done in LSA or ISS)
  3. M sure to add the distribution group to the environment info of the Lawson user (assuming you’re distributing a lawson job to other users).
  4. Open jobdef and add it now. NOTE: After adding to Jobdef, you can clear this field and it should still work.

 

How ERP Data Fits Into The Enterprise Data Ecosystem

Enterprise Resource Planning (ERP) data is no longer the center of the enterprise universe—it’s now part of a broader ecosystem. In a recent Forbes article, Robert Kramer from Moor Insights and Strategy explains how ERP’s role is shifting and why organizations must rethink how they manage and connect this critical data. For years, ERP systems served as the primary source of truth for operations like finance, inventory, and production. Today, that model is evolving. ERP is now one of several key systems contributing to a larger, interconnected data environment that includes customer platforms, supply chain tools, and external data. This shift is fueled by growing technology complexity, widespread SaaS adoption, and demand for faster, more contextual insights. Businesses don’t just want to know what happened—they want to understand why it happened and what to do next. That requires combining ERP data with signals from across the enterprise. As a result, organizations face important architectural decisions: where ERP data should live, how it integrates with other systems, and how to maintain consistent definitions and governance. Without a clear strategy, data can become fragmented or lose its meaning. At the same time, ERP vendors and data platform providers are expanding their capabilities to support this shift. Most companies will land on a hybrid approach, balancing ERP-native tools with broader data platforms. The takeaway is clear: ERP remains essential, but it’s no longer sufficient on its own. Organizations that deliberately integrate ERP into a connected data ecosystem will be better equipped to leverage AI, gain real-time insights, and make smarter, faster decisions.

 

For Full Article, Click Here

How Clean Core ERP Has Evolved Into a Mandate

Clean core ERP (enterprise resource planning) is no longer just a best practice—it’s becoming a mandate for modern manufacturing. In an ERP Today article, senior editor Chris Vavra explains why this approach is now critical for agility and scalability. “Clean core” means keeping ERP systems close to standard, avoiding heavy customizations and instead using approved APIs and extension platforms. This shifts the focus from customizing for each plant to standardizing the core while enabling innovation at the edges. The need is driven by operational realities. Legacy customizations slow upgrades, complicate integrations with systems like MES and supply chain platforms, and make multi-site standardization difficult. Clean core helps reduce downtime, accelerate updates, and improve consistency across operations. It also aligns with composable ERP, where ERP acts as a stable system of record connected to specialized applications. This allows IT teams to prioritize integration and innovation rather than maintaining fragile, plant-specific code. However, success requires strong governance. Organizations must clearly define when to standardize and when to extend. Over-standardization can create friction if local plant needs are ignored, so balance is essential. Ultimately, clean core transforms ERP into a flexible, reliable foundation. Companies that embrace it can adopt AI and automation faster, while maintaining control, consistency, and long-term scalability.

 

For Full Article, Click Here

Retiring a legacy system like Infor Lawson is one of the clearest paths to a clean core. See how APIX archives your Lawson data to AWS — fully managed, SOC 2 certified, with no ongoing maintenance burden.

Configuring LSA logging for the passive client

, ,

Follow the steps below to configure LSA logging for the passive client:

  1. Right mouse Click on the Lawson Security Administrator icon and run as Administrator
  2. On the upper right corner of the Server Connection form, click Settings.
  3. On the Settings form, select the Logging tab then configure the following:

    Configuration Directory

    Specify where LawsonNlog.Config is located. LawsonNlog.Config is the configuration setting for LawsonHttpClient that takes care of logging.

    Enable Logging- toggle logging.

    Log level

    Debug – Log the detailed trace

    Error – Log the exception errors

    Log Directory

    Provide the location where the generated logs will be saved on the same computer where LSA is installed.

  4. Select Apply, and Yes – to apply the settings before re-launching LSA.

 

Cloud ERP vs. on-premises ERP: Key differences

Cloud ERP (enterprise resource planning) vs. on-premises ERP is becoming a critical decision point for modern businesses as technology evolves. In an article by tech journalist Andy Patrizio for TechTarget, the shift toward cloud-based ERP is highlighted as vendors increasingly prioritize innovation—especially in areas like AI (artificial intelligence)—within cloud platforms rather than on-premises systems. Patrizio explains that while many organizations remain on on-prem ERP to maximize past investments or avoid disruption, the long-term trajectory favors cloud adoption. On-premises systems are stable and cost-effective to maintain, but they risk falling behind as innovation accelerates elsewhere. The differences between the two models are significant. Cloud ERP (typically SaaS) offers faster deployment, frequent automatic updates, built-in mobile access, and scalability. It also reduces internal IT burden since vendors manage infrastructure, maintenance, and security. However, this convenience comes with less control, limited customization, and ongoing subscription costs. In contrast, on-premises ERP provides greater control over systems and data, along with deeper customization options—ideal for organizations with complex or highly specific requirements. But it also demands higher upfront investment, longer implementation timelines, and continuous internal support. Security is no longer a clear advantage for on-prem systems, as cloud providers now offer robust, enterprise-grade protections and redundancy. Ultimately, Patrizio emphasizes that organizations should focus on their business needs rather than the deployment model itself. Even so, with innovation firmly centered in the cloud, the real question for most companies is not if they will transition—but when and to what extent.

 

For Full Article, Click Here

For organizations moving off legacy on-premises systems like Infor Lawson, APIX provides a fully managed Lawson data archiving solution — preserving 100% of your data in AWS with zero ongoing maintenance.

AWS Schema Conversion Tool Error 602

, ,

When migrating schemas to MySQL using the AWS Schema Conversion Tool (SCT), you may encounter the error:

“602: Converted tables might exceed the row-size limit in MySQL.”

This warning means that one or more tables being converted could exceed MySQL’s row-size limit. For the InnoDB storage engine (default in MySQL and Amazon Aurora MySQL), the maximum row length is 65,535 bytes. If your converted table design goes beyond this, MySQL will reject it.

Why This Happens

  • Large VARCHAR or TEXT columns
  • Too many columns in a single table
  • Wide columns that, when combined, exceed the 64KB limit
  • Non-optimized data types during schema conversion

Fixing the Issue

  1. Review and Optimize Column Data Types
  • Reduce overly large VARCHAR lengths. For example:
    • VARCHAR(1000) → VARCHAR(255) if values never exceed that length.
  • Replace TEXT with smaller types (TINYTEXT, MEDIUMTEXT) where possible.
  • Use integers (INT, SMALLINT, TINYINT) instead of BIGINT if values fit.
  1. Normalize the Table

If your schema has too many wide columns:

  • Split them into multiple related tables
  • Use foreign keys to maintain relationships
  • Store large blobs of data separately
  1. Drop Unnecessary Columns

Remove unused or redundant columns before migration to shrink the row size.

  1. Consider Storage Engine Options
  • InnoDB enforces the row-size limit but stores large TEXT/BLOB columns off-page (only a 20-byte pointer remains in the row).
  • If you only need full-text lookups, splitting those into reference tables may help.
  1. Change InnoDB Page Size (Advanced)

By default, InnoDB uses a 16KB page size. MySQL allows compilation with different page sizes (4KB, 8KB, 16KB, 32KB, 64KB).
⚠️ Important: This cannot be changed dynamically. You must recompile MySQL from source with a custom setting.

  • Download MySQL source
  • Modify the UNIV_PAGE_SIZE definition
  • Rebuild and reinstall MySQL
  • Re-import your schema and data

This approach is rarely used in practice because it complicates upgrades and maintenance, and is not supported on managed services like Amazon RDS or Aurora MySQL.

Best Practice in AWS Context

Since you’re working with AWS SCT and likely using Aurora MySQL or RDS, you cannot change InnoDB page size. Instead, the best fix is to:

  • Normalize your schema
  • Adjust column definitions
  • Split oversized tables

Takeaway

The 602 error in AWS SCT isn’t a hard failure—it’s a warning that your schema design may hit MySQL’s row-size limits. While increasing InnoDB page size is technically possible in self-managed MySQL builds, on AWS-managed databases the right solution is schema redesign and column optimization.

✅ Rule of thumb: If you’re migrating from Oracle, SQL Server, or DB2 into MySQL, review the largest tables carefully. Wide schemas that were fine in those engines may not fit in MySQL’s stricter row limits.

 

Why ERP Ecosystems Are A Strategic Architecture Decision

Enterprise Resource Planning (ERP) ecosystems are no longer just IT decisions—they’re central to business strategy and performance. In a recent Forbes article by Manish Goyal, co-founder of Dynamics Square, the core message is clear: treating ERP as a procurement exercise misses the bigger picture. The real differentiator is the strength of the underlying ecosystem. Goyal explains that modern ERP platforms—like Microsoft Dynamics 365, SAP, and Oracle—operate within integrated cloud environments that connect data, analytics, AI, and business processes. This integration enables faster decision-making, clearer insights, and greater operational agility. In contrast, fragmented systems create silos that slow organizations down. AI adoption further highlights this divide. While many companies are implementing AI, its value depends on integration. In cohesive ecosystems, AI can directly influence operations through forecasting and automation. In disconnected systems, it often remains limited to surface-level insights. However, ecosystem strategies come with trade-offs, including increased complexity, higher costs, and potential vendor dependency. Goyal stresses that success depends on aligning architecture with business goals—not just choosing a vendor. He also points out common pitfalls: treating ERP as an IT-only project, neglecting data governance, and over-customizing systems, which can limit future flexibility. The bottom line is ERP is not just software—it’s a strategic architecture decision. Organizations that prioritize integration, strong data foundations, and cross-functional alignment will gain a lasting competitive advantage.

 

For Full Article, Click Here