← Articles · proALPHA & XML

proALPHA & XML Part 1: System Architecture, pIW, and the proALPHA XML Data Model

In Part 1 of our four-part series, we examine the proALPHA ERP integration ecosystem, the proALPHA Integration Workbench (pIW), internal XML schema structures, and robust export/import pipeline architecture.

In Central European mechanical engineering, automotive tier-1/tier-2 supply chains, and discrete manufacturing, proALPHA ERP is one of the most prominent enterprise resource planning suites. While enterprise automotive and industrial trading partners traditionally mandate EDIFACT and VDA standards, modern integration pipelines, cloud procurement hubs, and statutory gateways increasingly rely on XML (Extensible Markup Language) as their primary interface and intermediate representation. In this four-part technical series, we explore bidirectional data exchange between proALPHA and XML, the internal data model, the proALPHA Integration Workbench (pIW), and the execution of standardized B2B flows (ORDERS, DESADV, INVOIC, Peppol, and tax authority XML).

Part 1 examines architectural foundations: how the internal proALPHA integration ecosystem operates, how native proALPHA XML documents are structured, character encoding and data type rules, and how to build a reliable export/import pipeline.

Technical Integration Foundations in proALPHA

proALPHA ERP is built upon the robust Progress OpenEdge database engine and ABL (Advanced Business Language) application server. For data integration, proALPHA delivers two central mechanisms:

  • proALPHA Integration Workbench (pIW): The built-in integration engine responsible for message definitions, field mappings, lifecycle state logging, transaction consistency, and error handling.
  • proALPHA Integration Service (pIS) & Web Services: REST and SOAP service layers facilitating near real-time synchronous or asynchronous communication with external middleware platforms (such as SEEBURGER BIS, Lobster_data, Altova MapForce, or custom API gateways).

In B2B automation, the proven pattern remains file-based and queued XML exchange: proALPHA triggers on business events (such as order release or delivery note posting), generating an internal XML file into a staged directory or queue. An external integration engine picks up the file, transforms it to EDIFACT or partner XML, and securely transmits it via AS2, OFTP2, or SFTP.

The Internal proALPHA XML Data Model

XML documents exported by proALPHA adhere to a clear, hierarchical layout. Business documents (sales orders, delivery notes, invoices) are organized into primary tiers:

<?xml version="1.0" encoding="UTF-8"?>
<proalphaDocument type="SalesOrder" version="9.1" xmlns="http://www.proalpha.com/schemas/piw">
    <Header>
        <DocumentID>AU-2026-04192</DocumentID>
        <DocumentDate>2026-10-21</DocumentDate>
        <TargetDeliveryDate>2026-10-28</TargetDeliveryDate>
        <Status>Released</Status>
        <Currency>EUR</Currency>
        <Incoterms>
            <Term>DAP</Term>
            <Location>Gyoer</Location>
        </Incoterms>
        <Parties>
            <Party role="Customer">
                <proalphaID>K-10084</proalphaID>
                <GLN>5999876543210</GLN>
                <VATNumber>HU12345678</VATNumber>
                <Name>Automotive Assembly Corp.</Name>
            </Party>
            <Party role="DeliveryAddress">
                <GLN>5999876543227</GLN>
                <City>Győr</City>
                <PostalCode>9027</PostalCode>
                <Street>Industrial Park St. 12.</Street>
            </Party>
        </Parties>
    </Header>
    <LineItems>
        <LineItem itemNo="10">
            <PartNumber>PA-55021</PartNumber>
            <CustomerPartNumber>CUST-88340-A</CustomerPartNumber>
            <GTIN>5991234567890</GTIN>
            <Description>Aluminum Engine Bracket Mount</Description>
            <Quantity unit="PCE">250.000</Quantity>
            <UnitPrice>48.50</UnitPrice>
            <NetLineAmount>12125.00</NetLineAmount>
            <ConfirmedDeliveryDate>2026-10-28</ConfirmedDeliveryDate>
        </LineItem>
    </LineItems>
</proalphaDocument>

Key Structural Elements

  1. DocumentID and Reference Keys: proALPHA internal business keys (e.g., AU-... for sales orders, BE-... for purchase orders, LI-... for delivery notes, RE-... for invoices).
  2. Partner Roles (Parties / Party): Multiple commercial parties attached to a single transaction (buyer, supplier, invoice recipient, delivery destination, end-user), containing internal proALPHA master IDs, international GLNs (Global Location Numbers), and tax IDs.
  3. Line Items (LineItems / LineItem): Line items featuring sequential position numbers (itemNo), internal and customer part numbers, precise quantities, and units of measure.

Data Types, Formats, and Syntax Rules

Discrepancies between proALPHA internal OpenEdge storage types and external B2B standards represent a frequent source of integration faults. The following conventions must be enforced:

Data TypeproALPHA Internal FormatB2B XML / EDIFACT TargetTransformation Notes
Date DD.MM.YYYY or YYYY-MM-DD ISO 8601: YYYY-MM-DD (EDIFACT format code: 102) Avoid timezone offsets when representing calendar business dates to prevent midnight shifts.
Decimals Decimal point (.), up to 3-4 decimals Strict decimal point (.), no thousands separators Never allow comma separators (,) in XML decimal values.
Units of Measure Internal abbreviations (e.g., Stk, kg, m) UN/ECE Rec 20 (PCE, KGM, MTR) Maintain a bidirectional cross-reference lookup table in pIW or mapping layer.
Character Encoding Progress UTF-8 or ISO-8859-15 Strictly UTF-8 (without BOM) Ensure clean encoding conversion without UTF-8 Byte Order Marks that crash strict XML parsers.

Triggering Pipelines and Processing Life Cycle

How do outbound and inbound document pipelines operate in proALPHA day-to-day operations?

Outbound Flow:

  1. Event-Driven Trigger: When an operator posts a delivery note or confirms an invoice, a proALPHA event trigger kicks off the pIW export procedure.
  2. XML Generation: The proALPHA ABL engine renders the XML structure according to the configured schema and stages it in the outbound filesystem directory (e.g., /edi/outbound/).
  3. Translation & Dispatch: The integration engine reads the file, executes EDIFACT mapping (e.g., DESADV D96A), and sends it across the AS2 link.
  4. Status Loopback: Upon successful transport confirmation, the middleware updates proALPHA document status (e.g., "EDI Sent") via file or API notification.

Inbound Flow:

  1. Message Ingestion: The trading partner delivers an EDIFACT ORDERS message across the AS2 endpoint.
  2. Translation to proALPHA XML: The converter transforms EDIFACT into the pIW inbound XML schema.
  3. pIW Ingestion & Business Validation: proALPHA pIW reads the XML document. Crucially, pIW does not perform raw database inserts; it executes full proALPHA application logic (price calculation, item availability, credit checks), creating a validated transaction record.

In Part 2 of our series, we dive into commercial orders and acknowledgments (ORDERS / ORDRSP), covering product code cross-referencing, price tolerance validation, and automated exception handling.