Developer ToolsFree referencePDF, Excel, Word exportInfor XAAll Infor XA tools

Infor XA API and Integration Options Reference

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.

Download:

Mechanism	Direction	Transport	Where configured	XA objects involved	Best for	Watch-outs
System-Link XML requests	Both	XML request and response documents	System-Link on the XA server	SLRHDR, SLRXML, SLRTXT	Creating and changing XA business objects from another system with XA validation	Requests run XA business logic, so test with the same authority the caller will use
System-Link request header	Inbound	Stored request	System-Link	SLRHDR (XML request header)	Tracing which requests were received	Monitor growth and clear old requests on a schedule
System-Link request text	Inbound	Stored request	System-Link	SLRXML (XML requests), SLRTXT (XML request text)	Seeing the exact XML a caller sent when a request fails	May hold business data; restrict authority to these files
System-Link request transformation	Inbound	Transformation of incoming XML	System-Link	SLRTRF (request transformation), SLRTRM (System-Link request transformation master)	Mapping a partner's XML shape to the XA request format	Transformations are site data; include them in upgrade testing
IDF objects and Integrator	Both	IDF object layer	IDF (Infor Development Framework)	IDF business objects and Integrator definitions	Object-level access with XA rules, extensions and custom objects	Needs IDF skills; keep extensions documented for each build
REST APIs built over IDF objects	Both	HTTP/JSON	Integrator or partner tooling (add-on)	IDF business objects	Modern apps and portals that expect REST	Not a built-in public REST catalog; scope, security and hosting are part of the project
Business object triggers	Outbound	XML produced on object events	XA trigger definitions	TRGMST (trigger master), TRGFLT (filter), TRGTGT (target)	Pushing order, item or shipment changes to another system as they happen	A filter that is too broad floods the target; test with production-like volumes
Trigger keys and field changes	Outbound	XML key values	XA trigger definitions	TRGKEY (XML key values), TRGFCD (field change definition), TRGXRF (master/filter/target xref)	Firing only when specific fields change	Field change definitions must be reviewed after file changes in a new release
User exits and APIs	Both	Program call	XA exit definitions	MZD3CPP (user exit/api detail)	Adding site logic at supported points without changing XA source	Exit programs must be recompiled and retested at each upgrade
Application exits	Both	Program call	XA exit definitions	MZCFREP (application exit)	Calling a site program from an application function	Keep an inventory of active exits; undocumented exits break upgrades
Power-Link	User interface	IDF-based graphical client	Client install and XA environment	IDF business objects	Users working with XA objects, cards and lists rather than green screens	Not an integration API; automating clicks is fragile
Net-Link and Secure Net-Link	User interface	Browser over HTTP/HTTPS; web components in a servlet container	NetLink.war deployed to Apache Tomcat or IBM WebSphere	IDF web components	Browser access to XA, including users outside the internal network	Regenerate the WAR when a new IDF build is applied; secure with TLS
ION via IDFIONAPI	Inbound to XA	BODs from ION through ION API	IDFIONAPI WAR on WebSphere, reachable by ION CE	IDF, IMS endpoint	Receiving inbound BODs from Infor ION in XA 10	Endpoint must be reachable from Infor OS; whitelist the Infor OS Portal IPs only
Db2 for i SQL or ODBC	Outbound (read)	SQL over ODBC/JDBC	IBM i host servers and user authority	AMFLIB physical files	Reporting, BI extracts, data warehouse loads	Keep it read-only; writing to XA files bypasses XA logic and history
CPYTOIMPF and CPYFRMIMPF	Both	Delimited files in the IFS	CL programs	Physical files or work files	Batch extracts and loads to staging files	Load into staging, not straight into AMFLIB files
Data queues	Both	IBM i *DTAQ objects	Site programs	Site-defined data queues	Low-latency hand-off between IBM i programs and external listeners	Custom code to maintain; define message formats carefully
Scheduled CL jobs	Both	Job scheduler (WRKJOBSCDE or a third-party scheduler)	IBM i job scheduler	CL programs and XA batch functions	Nightly extracts and file transfers	Make each job restartable and log its row counts

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.

Review your XA integration design

Tell us which systems need to exchange data with XA and we will suggest the mechanism for each flow and the authority each one needs.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

Choosing between System-Link and IDF

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

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

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.

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

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.

Frequently Asked Questions

Does Infor XA have a REST API?

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?

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?

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?

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.

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.

Talk to an Expert Explore More Free Tools