# Infor XA API and Integration Options Reference

> Source: https://netray.co/tools/infor-xa-integration-options-reference
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

One row per way of getting data into or out of Infor XA on IBM i, with direction, transport, the XA objects involved and the main watch-outs.

## Category

developer

## Erp

Infor XA

## Audience

- IBM i developer
- Integration architect
- ERP administrator

## Tool

**Kind:** worksheet

**Mode:** reference

**Columns:**

#### Mechanism

**Key:** mechanism

**Type:** text

#### Direction

**Key:** direction

**Type:** text

#### Transport

**Key:** transport

**Type:** text

#### Where configured

**Key:** config

**Type:** text

#### XA objects involved

**Key:** objects

**Type:** text

#### Best for

**Key:** best

**Type:** text

#### Watch-outs

**Key:** watch

**Type:** text

**Rows:**

**Mechanism:** System-Link XML requests

**Direction:** Both

**Transport:** XML request and response documents

**Config:** System-Link on the XA server

**Objects:** SLRHDR, SLRXML, SLRTXT

**Best:** Creating and changing XA business objects from another system with XA validation

**Watch:** Requests run XA business logic, so test with the same authority the caller will use

**Mechanism:** System-Link request header

**Direction:** Inbound

**Transport:** Stored request

**Config:** System-Link

**Objects:** SLRHDR (XML request header)

**Best:** Tracing which requests were received

**Watch:** Monitor growth and clear old requests on a schedule

**Mechanism:** System-Link request text

**Direction:** Inbound

**Transport:** Stored request

**Config:** System-Link

**Objects:** SLRXML (XML requests), SLRTXT (XML request text)

**Best:** Seeing the exact XML a caller sent when a request fails

**Watch:** May hold business data; restrict authority to these files

**Mechanism:** System-Link request transformation

**Direction:** Inbound

**Transport:** Transformation of incoming XML

**Config:** System-Link

**Objects:** SLRTRF (request transformation), SLRTRM (System-Link request transformation master)

**Best:** Mapping a partner's XML shape to the XA request format

**Watch:** Transformations are site data; include them in upgrade testing

**Mechanism:** IDF objects and Integrator

**Direction:** Both

**Transport:** IDF object layer

**Config:** IDF (Infor Development Framework)

**Objects:** IDF business objects and Integrator definitions

**Best:** Object-level access with XA rules, extensions and custom objects

**Watch:** Needs IDF skills; keep extensions documented for each build

**Mechanism:** REST APIs built over IDF objects

**Direction:** Both

**Transport:** HTTP/JSON

**Config:** Integrator or partner tooling (add-on)

**Objects:** IDF business objects

**Best:** Modern apps and portals that expect REST

**Watch:** Not a built-in public REST catalog; scope, security and hosting are part of the project

**Mechanism:** Business object triggers

**Direction:** Outbound

**Transport:** XML produced on object events

**Config:** XA trigger definitions

**Objects:** TRGMST (trigger master), TRGFLT (filter), TRGTGT (target)

**Best:** Pushing order, item or shipment changes to another system as they happen

**Watch:** A filter that is too broad floods the target; test with production-like volumes

**Mechanism:** Trigger keys and field changes

**Direction:** Outbound

**Transport:** XML key values

**Config:** XA trigger definitions

**Objects:** TRGKEY (XML key values), TRGFCD (field change definition), TRGXRF (master/filter/target xref)

**Best:** Firing only when specific fields change

**Watch:** Field change definitions must be reviewed after file changes in a new release

**Mechanism:** User exits and APIs

**Direction:** Both

**Transport:** Program call

**Config:** XA exit definitions

**Objects:** MZD3CPP (user exit/api detail)

**Best:** Adding site logic at supported points without changing XA source

**Watch:** Exit programs must be recompiled and retested at each upgrade

**Mechanism:** Application exits

**Direction:** Both

**Transport:** Program call

**Config:** XA exit definitions

**Objects:** MZCFREP (application exit)

**Best:** Calling a site program from an application function

**Watch:** Keep an inventory of active exits; undocumented exits break upgrades

**Mechanism:** Power-Link

**Direction:** User interface

**Transport:** IDF-based graphical client

**Config:** Client install and XA environment

**Objects:** IDF business objects

**Best:** Users working with XA objects, cards and lists rather than green screens

**Watch:** Not an integration API; automating clicks is fragile

**Mechanism:** Net-Link and Secure Net-Link

**Direction:** User interface

**Transport:** Browser over HTTP/HTTPS; web components in a servlet container

**Config:** NetLink.war deployed to Apache Tomcat or IBM WebSphere

**Objects:** IDF web components

**Best:** Browser access to XA, including users outside the internal network

**Watch:** Regenerate the WAR when a new IDF build is applied; secure with TLS

**Mechanism:** ION via IDFIONAPI

**Direction:** Inbound to XA

**Transport:** BODs from ION through ION API

**Config:** IDFIONAPI WAR on WebSphere, reachable by ION CE

**Objects:** IDF, IMS endpoint

**Best:** Receiving inbound BODs from Infor ION in XA 10

**Watch:** Endpoint must be reachable from Infor OS; whitelist the Infor OS Portal IPs only

**Mechanism:** Db2 for i SQL or ODBC

**Direction:** Outbound (read)

**Transport:** SQL over ODBC/JDBC

**Config:** IBM i host servers and user authority

**Objects:** AMFLIB physical files

**Best:** Reporting, BI extracts, data warehouse loads

**Watch:** Keep it read-only; writing to XA files bypasses XA logic and history

**Mechanism:** CPYTOIMPF and CPYFRMIMPF

**Direction:** Both

**Transport:** Delimited files in the IFS

**Config:** CL programs

**Objects:** Physical files or work files

**Best:** Batch extracts and loads to staging files

**Watch:** Load into staging, not straight into AMFLIB files

**Mechanism:** Data queues

**Direction:** Both

**Transport:** IBM i *DTAQ objects

**Config:** Site programs

**Objects:** Site-defined data queues

**Best:** Low-latency hand-off between IBM i programs and external listeners

**Watch:** Custom code to maintain; define message formats carefully

**Mechanism:** Scheduled CL jobs

**Direction:** Both

**Transport:** Job scheduler (WRKJOBSCDE or a third-party scheduler)

**Config:** IBM i job scheduler

**Objects:** CL programs and XA batch functions

**Best:** Nightly extracts and file transfers

**Watch:** Make each job restartable and log its row counts

**Notes:** System-Link and trigger file names are from the Infor XA 9.2.0 table definition list (library AMFLIB). Net-Link and IDFIONAPI deployment details are from the Infor XA Setup Guide for Secure Net-Link (XA 9.2 and 10). Check BOD support for your release in the Infor XA documentation before designing an ION flow.

## Content

**Intro:** A reference table of the ways to integrate with Infor XA on IBM i: System-Link XML requests, IDF objects, business object triggers, user and application exits, Net-Link, ION through IDFIONAPI, Db2 SQL and file transfer. Each row shows direction, transport, the XA objects involved and the watch-outs that matter in a real project.

**Sections:**

#### Choosing between System-Link and IDF

**Body:** System-Link is the long-standing XML interface: a caller sends an XML request and XA processes it through its own business logic, storing request headers and text in SLRHDR, SLRXML and SLRTXT, with optional transformations in SLRTRF and SLRTRM. It suits partner systems that can produce XML and need XA validation. IDF (Infor Development Framework) is the object layer behind Power-Link and Net-Link; working at that level gives access to IDF business objects, extensions and custom objects, and it is the base for REST APIs built through Integrator or partner tooling. Pick System-Link when an existing XML request already does the job, and IDF when you need objects, extensions or a REST front end.

#### How triggers produce outbound events

**Body:** XA business object triggers are defined in the trigger master TRGMST, narrowed by filters in TRGFLT and sent to targets in TRGTGT. TRGKEY holds the XML key values and TRGFCD the field change definition, so a trigger can fire only when a chosen field changes, for example a promised date on an order line. TRGXRF cross-references master, filter and target. This is the right way to push changes out of XA as they happen. The common failure is a filter that is too broad, which floods the target system and slows interactive work, so test triggers with production-like volumes before go-live.

#### Read-only SQL versus transactional APIs

**Body:** Direct Db2 for i SQL over AMFLIB is the fastest route for reporting, BI and AI assistants: the IBM i host servers accept ODBC or JDBC connections and you read the physical files with a profile that has read authority only. Do not write to XA files with SQL. An update that skips XA logic leaves balances, history and audit records out of step and is hard to find later. Anything that creates or changes business data should go through System-Link, IDF or a supported exit, so XA applies its own validation and writes its own history.

**Bullets:**

- Reporting and AI: read-only SQL profile, library qualified, no *ALLOBJ
- Create or change orders: System-Link request or IDF object
- Event push: business object trigger with a narrow filter
- Bulk loads: CPYFRMIMPF into a staging file, then an XA-supported load

#### Security: XA security versus IBM i object authority

**Body:** XA has its own application security, held in files such as MZF0REP (user) and MZGUCPP (user security), which controls what a user can do inside XA functions. IBM i object authority controls whether a profile can open a file at all. Integrations often run under a service profile, and an ODBC connection ignores XA application security completely: if the profile can read AMFLIB/OPNPAYM, it reads every vendor invoice. Give integration profiles the minimum object authority, keep separate profiles per integration so activity can be traced, and put web components such as Net-Link behind TLS and a firewall rather than exposing the IBM i directly.

**Cta:** If you want an AI assistant that reads XA through a read-only SQL profile and hands any change back through System-Link with human approval, we can build that on your own servers.

**Faq:**

#### Does Infor XA have a REST API?

**Answer:** XA does not ship a public REST catalog in the way cloud ERPs do. REST APIs can be built over IDF business objects using Integrator or partner tooling, which is an add-on project with its own hosting and security design. For many needs, System-Link XML requests or read-only SQL already cover the requirement.

#### What is Infor XA Power-Link?

**Answer:** Power-Link is the IDF-based graphical client for XA. It presents XA business objects in a modern interface instead of green screens, and Net-Link is the browser-based equivalent. Power-Link is a user interface, not an integration API, so automate through System-Link, IDF or triggers rather than through the client.

#### How do I send XA changes to another system in real time?

**Answer:** Use XA business object triggers. Define the trigger in TRGMST, restrict it with a filter (TRGFLT) and, where needed, a field change definition (TRGFCD), and send it to a target defined in TRGTGT. The trigger produces XML with key values from TRGKEY that the receiving system can process.

#### Can Infor XA connect to Infor ION?

**Answer:** Yes. For XA 10, Infor documents an IDFIONAPI component, generated as a WAR file and deployed to WebSphere, that lets ION CE send inbound BODs to XA through ION API. The endpoint must be reachable from Infor OS, so only the Infor OS Portal IP addresses should be allowed through the firewall.

## Search terms

infor xa api, infor xa rest api, infor xa erp api, infor xa integration, infor xa power link, infor xa powerlink, infor xa system-link, mapics xa triggers

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