Key Capabilities
- IATA PADIS support with bidirectional IATA PADIS/XML translation
- Automatic EDIFACT-subset schema detection and validation for aviation industry messaging
- CONTRL acknowledgment generation/processing with interchange header management for routing
Overview
When receiving PADIS documents, IATA PADIS connectors validate document interchange headers and convert the PADIS document into XML. This is useful as a staging step, because XML is the primary format that Arc uses to manipulate data in a flow. The IATA PADIS connector automatically reads the input file to determine the appropriate PADIS schema, then parses the document according to this schema. IATA PADIS is a subset of the EDIFACT standard, so many of the features and functionality of the IATA PADIS connector are shared with the more general EDIFACT connector. When generating PADIS documents, IATA PADIS connectors convert XML into PADIS document syntax and apply the appropriate interchange headers. This is useful as the final step for creating a PADIS document, after the XML data has been fetched and transformed elsewhere in the flow.Connector Configuration
This section contains all of the configurable connector properties.Settings Tab
Translation Configuration
Settings related to the core operation of the connector.EDI Partner
Interchange Settings
Settings related to the IATA PADIS interchange headers. When generating PADIS documents from XML, these settings are used to generate document headers. When parsing PADIS documents, these settings are used to validate the incoming document.Acknowledgments
Settings related to generating and requesting acknowledgments.Sample Files Tab
Advanced Tab
EDI Delimiters
Settings that specify which characters separate elements, segments, etc.Interchange Settings
Additional settings related to the IATA PADIS interchange headers. These options appear or disappear based on the Syntax Version specified on the Settings tab.Functional Group Settings
Settings related to the functional group headers of PADIS documents. These optional identifiers can help group similar interchanges together or facilitate sub-addressing within an organization.Advanced Settings
Settings not included in the previous categories.Message
Message settings determine how the connector searches for messages and manages them after processing.
Note: The settings below are deprecated and hidden by default. They appear only on connectors where they were previously enabled or configured to a non-default value. To retain copies of successfully processed files, right-click the connector in the flow, choose Show Success Path, and connect the success path to a File connector.
| Setting | Description |
|---|---|
| Save to Sent Folder (Deprecated) | Copies files processed by the connector to the Sent folder. Disabled by default. Files saved to the Sent folder are not covered by Encryption at Rest. |
| Sent Folder Scheme (Deprecated) | Groups files in the Sent folder by the selected time interval. Only relevant when Save to Sent Folder is enabled. |
Logging
Settings that govern the creation and storage of logs.
| Setting | Description |
|---|---|
| Log Level | The verbosity of logs generated by the connector. When you request support, set this to Debug. |
| Log Subfolder Scheme | Instructs the connector to group files in the Logs folder according to the selected interval. The Weekly option (which is the default) instructs the connector to create a new subfolder each week and store all logs for the week in that folder. Leaving this setting blank tells the connector to save all logs directly in the Logs folder. For connectors that process many transactions, using subfolders helps keep logs organized and improves performance. |
| Log Messages | Check this to have the log entry for a processed file include a copy of the file itself. If you disable this, you might not be able to download a copy of the file from the Transactions tab. |
Miscellaneous
Miscellaneous settings are for specific use cases.
| Setting | Description |
|---|---|
| Other Settings | Enables you to configure hidden connector settings in a semicolon-separated list (for example, setting1=value1;setting2=value2). Normal connector use cases and functionality should not require the use of these settings. |
EDI Partners Tab
Automation Tab
Automation
Settings related to the automatic processing of files by the connector.Performance
Settings related to the allocation of resources to the connector.
| Setting | Description |
|---|---|
| Max Workers | The maximum number of worker threads consumed from the threadpool to process files on this connector. If set, this overrides the default setting on the Performance Settings portion of the Advanced Settings page. |
| Max Files | The maximum number of files sent by each thread assigned to the connector. If set, this overrides the default setting on the Performance Settings portion of the Advanced Settings page. |
Alerts Tab
SLAs Tab
Converting Formats
The following sections detail the process of converting PADIS documents to XML and vice versa.PADIS to XML
Setting the Translation Type to IATA to XML instructs the connector to parse incoming PADIS documents into XML. The connector first reads all of the header information for the Interchange and Functional Group sections of the document and validates them against the configured connector settings (unless Test Indicator is enabled). The connector then parses out the specific PADIS schema used in the document and loads the schema from theedifact_schemas folder on disk (additional schema files can be downloaded from our website for free).
Using the schema, the connector generates XML representing the structure of the document, populates the XML with the values from the document, and provides context to each value either as XML comments or as attributes in the XML elements (based on the value of Generate Descriptions As).
To see this process with a set of test PADIS documents, navigate to the Transactions tab of an IATA PADIS connector (with Translation Type set to IATA to XML) and select More > Create Test Files. PADIS documents for an invoice, purchase order, purchase order acknowledgment, and shipping notice are automatically generated and placed in the Transactions directory. After these test files are processed by the connector, navigate to the Transactions tab to see the resulting XML.
Once PADIS documents are converted to XML, the data can be transformed and manipulated in many ways. Commonly, PADIS data needs to be stored in a database or other back-end application system. Since Arc uses XML to represent inserts into these back-end systems, storing the PADIS data becomes a matter of mapping one XML structure onto another. This is typically done with the visual designer-driven XML Map Connector.
XML to PADIS
Setting the Translation Type to XML to IATA instructs the connector to generate a PADIS document out of an XML representation of the document. After the connector has constructed the PADIS message out of the data parsed from the XML, it adds functional group and interchange headers according to the configured connector settings. To see this process with a set of test XML files, navigate to the Transactions tab of an IATA PADIS connector (with Translation Type set to XML to IATA) and select More > Create Test Files. XML files representing an invoice, purchase order, purchase order acknowledgment, and shipping notice are automatically generated and placed in the Transactions directory. After these test files are processed by the connector, navigate to the Transactions tab to see the resulting PADIS document.Use With the XML Map Connector
Upload Test File
IATA PADIS Acknowledgments
The following sections detail the two types of IATA PADIS acknowledgments (ACKs), and how Arc expects, processes, and generates ACKs.Technical versus Functional Acknowledgments
Technical ACKs, sometimes called interchange ACKs, are an indication that an interchange has taken place between the two parties, although not necessarily that any individual message has been exchanged. These serve as a receipt to the sender indicating that the PADIS message was successfully received, but it does not specify whether there were any issues with processing the message content. Functional ACKs are an indication that an interchange has been processed by the receiving party. They can report acceptance, acceptance with issues, or rejection of the received document. These serve as both a receipt that an interchange was successfully received and that it was fully processed.Expecting, Processing, and Generating Acknowledgments
Expecting Acknowledgements
IATA PADIS connectors operating in XML to IATA mode can be configured so that technical and/or functional ACKs are expected for a message. When one or both Technical acknowledgment (CONTRL) and Functional acknowledgment (CONTRL) are checked in the Acknowledgments section of the Settings tab, the connector maintains a Pending ACK status for a transmission until the appropriate ACKs have been returned and processed. This means that the connector status can be used to determine whether the recipient has confirmed that they received the interchange. See the EDIFACT connector for a detailed description of this feature. The IATA PADIS connector works the same way.When EDI messages that require an acknowledgement have not received that acknowledgement, a Pending-Timeout header is added to the message. The message has a Pending status while it waits for its ACK. If it does not receive the ACK within the allotted time, the Pending-Timeout header is populated with the date and time when the message status changed to Error. When the ACK is received and the message is updated to Success, a new header is added with an empty string value.