# How to extend business logic in Infor LN with DAL2

> Source: https://netray.co/erp-help/ln-dal2-business-logic-extension
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

DAL2 lets you add custom validation, defaulting and calculation logic to Infor LN Enterprise Edition tables by writing a Java business logic handler class and registering it against a table event, without editing the standard DAL. Because the logic sits in your own package rather than inside Infor's base code, it survives upgrades that would otherwise overwrite a direct DAL change.

## Kind

advanced

## System

infor-ln

## Erp

Infor LN

## Module

LN Studio / DAL2 Business Logic

## Query

how to extend business logic in Infor LN without modifying standard DAL

## Alternate Queries

- infor ln dal2 custom validation
- dal2 business logic handler example infor ln
- how does dal2 work in infor ln
- infor ln customization without changing base code

## Applies To

Infor LN Enterprise Edition (LN Studio, Java-based DAL2 runtime)

## Steps

### Add a DAL2 business logic extension

**Items:**

- Open Infor LN Studio and connect to your development VRC (Version-Release-Customer) package combination.
- In the Package Explorer, create or open a custom package that is separate from Infor's standard packages; never edit a standard package directly.
- Create a Java class that extends the business logic handler for the table you want to affect, targeting the event you need (for example a validate or before-store event).
- Write the condition or default in the handler using the DAL2 API to read and set field values on the business object.
- Register the handler against the table and event, specifying the sequence relative to any standard handlers already on that event.
- Compile the package in LN Studio and resolve any dependency or field-reference errors against the base table definition.
- Deploy the package to a test VRC and run the affected session end to end to confirm the handler fires as expected.
- Check the LN application log for handler execution and for any exceptions thrown from your class.
- Promote the package through test and acceptance VRCs before production, following your normal Infor LN change control process.

## Sections

### Why DAL2 instead of classic DAL

**Body:**

Classic DAL is procedural 4GL logic compiled per table inside a VRC package. Editing it directly to add a custom rule means your change lives inside code Infor owns, so the next patch or upgrade can silently overwrite or conflict with it.

DAL2 solves this by layering Java business logic handlers on top of the base logic instead of inside it. Each handler is a separate class, registered against a table and event, that runs alongside the standard behavior rather than replacing it.

This matters most for Infor LN Enterprise Edition sites on the Java-based runtime, where DAL2 and LN Studio are the supported customization path and classic 4GL DAL editing is discouraged for exactly this upgrade-safety reason.

### Handler types and events

**Body:**

DAL2 handlers typically attach to events such as validate, before-store and after-store on a table's business object. A validate or before-store handler can reject the action outright by raising a business logic exception with your own message text.

An after-store handler is useful for logic that needs the record to already exist, such as triggering a downstream update once a header is saved. Default-value logic is usually set in a before-store or field-level handler so the value is in place before the record commits.

### Packaging and VRC discipline

**Body:**

Keep every DAL2 extension in its own custom package, never inside an Infor-owned package, and follow a clear naming convention so anyone reviewing the package structure can immediately tell which handlers are custom.

On upgrade, the base VRC and its packages get replaced while your custom package is untouched, but that is not a guarantee nothing breaks. If the target table's structure changed, your handler can reference a field that moved or was renamed, so re-test every DAL2 extension against the new VRC rather than assuming it just keeps working.

### A common pattern: reject and default in one place

**Body:**

A frequent real-world use of DAL2 is combining a rejection rule with a default value on the same table, for example blocking a negative quantity while defaulting a custom classification field. Both live in the same handler class so the rule is easy to find and maintain later.

**Code:**

// Illustrative DAL2 handler pattern (conceptual, not a literal SDK signature)
public class SalesOrderLineValidator extends BusinessLogicHandler {
  public void beforeStore(BusinessObject bo) {
    if (bo.getDecimal("orderedQuantity") < 0) {
      throw new BusinessLogicException("Ordered quantity cannot be negative");
    }
    if (bo.getString("customClass") == null) {
      bo.setString("customClass", "STANDARD");
    }
  }
}

## Pitfalls

- Editing the standard DAL directly instead of using a DAL2 extension, which gets lost on the next patch or upgrade.
- Registering a handler without checking the execution order of existing standard handlers, causing double validation or a skipped default.
- Assuming a DAL2 extension will keep working after an LN upgrade without re-testing it against the new VRC.
- Throwing raw exceptions instead of a clear business logic exception, so end users see a generic error instead of a useful message.
- Mixing DAL2 Java logic and classic 4GL DAL customization on the same table, so business rules end up split across two technologies.
- Deploying straight to production without promoting through test and acceptance VRCs and re-checking dependent sessions like order-to-invoice.

## Ai Angle

A developer assistant grounded in your LN package structure can scan the handlers already registered on a table before you add a new one, flag a conflicting event sequence, and draft the validate or before-store skeleton with your team's naming conventions already applied, so review time goes into the business rule itself rather than package plumbing.

## Faq

### What is the difference between DAL and DAL2 in Infor LN?

**Answer:** Classic DAL is procedural 4GL logic compiled per table inside a VRC package. DAL2 is Java-based business logic layered on top through registered handler classes, introduced for LN Enterprise Edition so customizations survive upgrades without patching base tables.

### Can I use DAL2 on a classic (non-Java) Infor LN installation?

**Answer:** No. DAL2 requires the LN Enterprise Edition Java-based runtime and LN Studio. Installations still on the classic 4GL runtime use traditional DAL customization or session-level scripting instead.

### Where do I register a DAL2 handler?

**Answer:** Inside LN Studio, against the table you are extending, specifying the event (such as validate or before-store) and the class implementing the handler, then compiling and deploying the containing package to your VRC.

### Will a DAL2 extension break during an Infor LN upgrade?

**Answer:** It can, if the underlying table structure, field name or business object interface changes between releases. Re-test every custom handler against the new VRC before go-live rather than assuming it will keep working unchanged.

## Search terms

infor ln dal2, dal2 business logic handler, infor ln customization without modifying dal, infor ln studio java extension, infor ln upgrade safe customization, dal vs dal2 infor ln, infor ln business logic handler example, infor ln enterprise edition customization, baan dal2 tutorial, infor ln package explorer

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json