Design and test Java transformers for IFS Connect
Documentation-based guide draft · Reviewed against sources on 2026-09-27 · Not executed in an IFS environment. IFS references use 26R1 unless stated otherwise. Confirm available APIs, components, and permissions in your installed release.
Build an original, deliberately small IFS Connect string transformer, test its formatting logic locally, then upload it to a development transformer configuration. The example converts a strict three-field text message into a normalized line; it is not a general CSV parser.
Before you start
Section titled “Before you start”Use a JDK compatible with the target IFS Connect runtime and framework JARs from the matching release. Obtain ifs-fnd-connect.jar and its required base/common dependencies through your authorized development tooling. Do not substitute unrelated JAR versions just to make compilation succeed.
Create a workspace with src, lib, and out folders. Put the required framework JARs in lib. The documented transformer class must be in the default package: do not add a package declaration.
1. Define a tiny input contract
Section titled “1. Define a tiny input contract”The input contains exactly three pipe-separated fields: message ID, equipment reference, and integer reading. A valid example is LAB-009|PUMP-3|18. Fields may not contain embedded pipes, quotes, or newlines. Invalid input must fail before producing a partial output.
2. Implement the transformer
Section titled “2. Implement the transformer”Save this as src/NormalizeReading.java:
import ifs.fnd.base.IfsException;import ifs.fnd.connect.xml.Transformer;
public class NormalizeReading implements Transformer { @Override public void init() throws IfsException { }
@Override public String transform(String input) throws IfsException { return normalize(input); }
public static String normalize(String input) { if (input == null || input.contains("\n") || input.contains("\r")) { throw new IllegalArgumentException("One input line required"); } String[] fields = input.split("\\|", -1); if (fields.length != 3 || !fields[0].matches("[A-Z0-9-]{1,40}") || !fields[1].matches("[A-Z0-9-]{1,40}")) { throw new IllegalArgumentException("Invalid message fields"); } int reading = Integer.parseInt(fields[2]); return fields[0] + "," + fields[1] + "," + reading; }}The transformation is deterministic and has no HTTP calls, database writes, shared mutable fields, or secrets. It is therefore straightforward to reproduce a failure from its input.
3. Add a local fixture check
Section titled “3. Add a local fixture check”Save src/NormalizeReadingTest.java:
public class NormalizeReadingTest { public static void main(String[] args) { String result = NormalizeReading.normalize("LAB-009|PUMP-3|18"); if (!"LAB-009,PUMP-3,18".equals(result)) { throw new AssertionError(result); } try { NormalizeReading.normalize("LAB-009|PUMP-3|not-a-number"); throw new AssertionError("Invalid input was accepted"); } catch (NumberFormatException expected) { System.out.println("Positive and negative fixtures passed"); } }}From that workspace on Windows, compile and run:
javac -cp "lib/*" -d out src/NormalizeReading.java src/NormalizeReadingTest.javajava -cp "out;lib/*" NormalizeReadingTestExpected result: the fixture message, with no unexpected exception. These are instructions for your environment; this guide does not claim compilation against your IFS libraries has been performed.
4. Package only the implementation
Section titled “4. Package only the implementation”Create MANIFEST.MF with a final blank line:
Manifest-Version: 1.0Transformer-class: NormalizeReadingBuild the JAR:
jar cfm NormalizeReading.jar MANIFEST.MF -C out NormalizeReading.classDo not include the test class, private keys, or copied IFS runtime JARs. If you later add your own helper classes or permitted third-party dependencies, package them according to the documented transformer loading requirements.
5. Upload and route in development
Section titled “5. Upload and route in development”Open Solution Manager → Integration → IFS Connect → Setup IFS Connect. Create a transformer with instance type JavaTransformer, a unique lab name, and a clear description. Upload NormalizeReading.jar as TRANSFORMER_FILE. Connect it to the intended address in a development Message Routing rule.
Send the same valid fixture through that route. Compare the transformed message with the local expected output. Send the invalid numeric fixture and confirm a visible transformer failure with no downstream business update.
6. Troubleshoot and roll back
Section titled “6. Troubleshoot and roll back”A class-version error means the compilation target and runtime disagree. A missing class indicates a dependency or packaging problem. A class-loading error can result from a package declaration or incorrect Transformer-class value. A local success with incorrect runtime output usually points to another transformer/routing configuration being used.
Preserve the previous transformer file before replacement. To roll back, stop test traffic, restore the old file/routing association, and replay only messages whose downstream result is known. Remove the lab transformer after disconnecting its route.
Detailed references: transformer interfaces and configuration fields.
Sources and scope
Section titled “Sources and scope”Older IFS Applications examples are historical context, not evidence of Cloud compatibility. No third-party code, screenshots, or downloadable workflows are reproduced.