IATA PADIS Connector
IATA PADIS Connector
IATA PADIS Connectors support generating PADIS documents from XML and converting PADIS documents into XML.
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, as XML is the primary format that CData Arc uses to manipulate data within a flow. The IATA PADIS Connector automatically reads the input file to determine the appropriate EDIFACT schema, then parses the document according to this schema. IATA PADIS is a subset of the EDIFACT standard, and 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 an IATA PADIS document, after the XML data has been fetched and transformed elsewhere in the flow.
Note that interchange header validation can be avoided by enabling the Test Indicator setting.
An IATA PADIS Connector can also automatically generate acknowledgments to incoming PADIS documents.
This section contains all of the configurable connector properties.
Settings related to how the connector will attempt to translate input files.
- Connector Id The static name of the connector. All connector-specific files are contained in a folder by the same name within the Data Directory.
- Connector Description An optional field to provide free-form description of the connector and its role in the flow.
- Translation Type Whether the connector is converting an PADIS document into XML or XML data into an PADIS document.
Settings related to the interchange headers of PADIS documents. When generating PADIS documents, these settings are applied as interchange headers in the resulting document. When parsing PADIS documents, the interchange settings are used to validate the incoming document.
- Syntax Identifier (UNB1.1) Identifies the character set used in the PADIS document.
- Syntax Version (UNB1.2) In combination with the Syntax Identifier determines the syntax to be used in the PADIS document. The available elements for interchange settings may change depending on this value.
- Service Code List Directory Version Number (UNB1.3) Further specifies the syntax to be used in the PADIS document. Only applicable for EDIFACT syntax version 4.
- Character Encoding (UNB1.4) Specifies how characters are encoded (e.g. ASCII, UTF-8). Only applicable for EDIFACT syntax version 4.
- Sender Identifier (UNB2.1) The unique ID identifying the sending party in the communication (when generating an PADIS document, this should be your identifier).
- Sender Code Qualifier (UNB2.2) The qualifier for the Sender Identifier, providing context to the value (e.g. EAN location number).
- Address for Reverse Routing (UNB2.3) The optional address within the sender’s system to which responding interchanges should be sent. Only applicable for EDIFACT syntax versions earlier than version 4.
- Sender Internal ID (UNB2.3) An additional sender identifier to facilitate internal routing of response interchanges. Only applicable for EDIFACT syntax version 4.
- Sender Internal Sub-Identification (UNB2.4) Further identifies the sender, for when sub-level identification is required. Only applicable for EDIFACT syntax version 4.
- Recipient Identifier (UNB3.1) The unique ID identifying the receiving party in the communication (when generating an PADIS document, this should be your partner’s identifier).
- Recipient Code Qualifier (UNB3.2) The qualifier for the Recipient Identifier, providing context to the value (e.g. EAN location number).
- Routing Address (UNB3.3) The optional address within the recipient’s system to which interchanges should be routed. Only applicable for EDIFACT syntax versions earlier than version 4.
- Recipient Internal ID (UNB3.3) An additional recipient identifier to facilitate internal routing of received interchanges. Only applicable for EDIFACT syntax version 4.
- Recipient Internal Sub-Identification (UNB3.4) Further identifies the recipient, for when sub-level identification is required. Only applicable for EDIFACT syntax version 4.
- Recipient Password (UNB6.1) Reference or password to gain access to the recipient’s system.
- Recipient Password Qualifier (UNB6.2) The qualifier that provides context to the Recipient Password, if applicable.
- Application Reference ID (UNB7) Identifies the application group to which the messages in the interchange relate.
- Processing Priority Code (UNB8) Code for requesting processing priority for the interchange.
- Communication Agreement (UNB10) Defines the type of communication agreement controlling the interchange.
- Test Indicator (UNB11) Whether the interchange is in test mode or production mode. If this setting is enabled when receiving documents, interchange headers will not be validated.
Functional Group Settings
Settings related to the functional group headers of PADIS documents. These optional identifiers may help group similar interchanges together or facilitate sub-addressing within an organization.
- Application Sender Identifier (UNG2.1) Identifies the application sending the document (e.g. a division, branch, or computer system).
- Application Recipient Identifier (UNG2.1) Identifies the application for which the document is intended.
Settings related to generating and requesting acknowledgments.
- Technical acknowledgment (CONTRL) expected Whether a technical CONTRL ACK should be returned (when receiving) and requested (when sending). A technical acknowledgment serves as a receipt of the interchange.
- Functional acknowledgment (CONTRL) expected Whether a functional CONTRL ACK should be returned (when receiving) and requested (when sending). A functional acknowledgment serves as an indication of acceptance or rejection of the received interchange.
- Route ACKs to Connector The specified connector will generate acknowledgments using the transaction data received by the current connector. The specified connector adds interchange headers and passes the acknowledgment along in the flow like any other message. Thus this should typically be set to a pre-configured IATA PADIS Connector that generates outbound documents for the intended recipient.
Settings related to the automatic processing of files by the connector.
- Send A toggle that instructs the connector to automatically send files when they are ready.
- Retry Interval The interval the connector will wait before retrying a failed send.
- Max Attempts The number of attempts the connector will make to send the message. Setting this value to 1 instructs the connector to only make the initial send attempt without retrying. The connector waits the duration specified by Retry Interval between each attempt.
Settings that specify which characters separate elements, segments, etc.
- Data Element Separator The character that separates individual data elements within the document.
- Component Element Separator The character that separates elements within a composite data structure in the document.
- Segment Terminator The character that indicates the end of a segment within the document.
- Release Char The character that ‘releases’ or ‘escapes’ the next character, overriding its usual meaning. This allows reserved characters to appear as data withing documents, as long as they are preceded by the Release Char.
- Repetition Char The character that indicates repetition of element values.
- Suffix Appended to the Segment Terminator to distinguish segments.
Settings related to the allocation of resources to the connector.
- Max Workers The maximum number of worker threads that are consumed from the threadpool to process files on this connector. If set, this overrides the default setting on the Profiles page.
- Max Files The maximum number of files that are processed by the connector each time worker threads are assigned to the connector. If set, this overrides the default setting on the Profiles page.
Settings not included in the previous categories.
- Batch Transactions Whether multiple transactions should be grouped together in a single output file. If false, each transaction found in the interchange will result in a separate output document.
- Element Ref By ID When translating PADIS into XML, whether reference ID’s will be used to name XML elements, for example:
If false, the Reference designator will be used to name XML elements:
- Expand Qualifier Values When translating PADIS into XML, whether elements containing an EDI qualifier will have child elements ‘Code’ and ‘Value’ to express the qualifier code and value. For example:
- Generate Description As When translating PADIS into XML, descriptions of the EDIFACT segments and elements will be provided as context for the PADIS data. This context can be added as an XML comment or included within the XML elements as XML attributes. Use this setting to determine which of these approaches, or neither, is used.
- Send Filter A glob pattern filter to determine which files in the Send folder will be processed by the connector (e.g. *.edi). Negative patterns may be used to indicate files that should not be processed by the connector (e.g. -*.tmp). Multiple patterns may be separated by commas, with later filters taking priority except when an exact match is found.
- Local File Scheme A filemask for determining local file names as they are processed by the connector. The following macros may be used to reference contextual information:
%ConnectorId%, %Filename%, %FilenameNoExt%, %Ext%, %ShortDate%, %LongDate%, %RegexFilename:%, %DateFormat:%, %ControlNumber%, %TransactionControlNumber%, %TransactionCode%, %StandardVersion%.
As an example: %FilenameNoExt%_%ControlNumber%%Ext%
- Parent Connector The connector from which settings should be inherited, unless explicitly overwritten within the existing connector configuration. Must be set to a connector of the same type as the current connector.
- Strict Schema Validation Whether the connector should Ignore, Warn, or Fail when the following are detected: Repeat counts above the allowed number; missing required elements/segments; invalid qualifier and code values; disallowed element lengths; invalid element values.
- Log Messages Whether logs from processed files will include a copy of the file itself.
- Save to Sent Folder Whether files processed by the connector should be copied to the Sent folder for the connector.
Miscellaneous settings are for specific use cases.
- 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.
The following sections detail the process of converting IATA PADIS to XML and vice versa.
EDI to XML
Setting the Translation Type to EDI-to-XML will instruct 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 EDIFACT schema used in the document and loads the schema from the ‘edifact_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 within the XML elements (depending on the value of Generate Descriptions As).
To see this process with a set of test PADIS documents, navigate to the Input tab of an IATA PADIS Connector (with Translation Type set to EDI-to-XML) and select More > Create Test Files. EDIFACT documents for an Invoice, Purchase Order, Purchase Order Acknowledgment, and Shipping Notice will be automatically generated and placed in the Input directory. After these test files are processed by the connector, navigate to the Output 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 simply mapping one XML structure onto another. This is typically done with the visual designer-driven XML Map Connector.
XML to EDI
Setting the Translation Type to XML-to-EDI will instruct the connector to generate an 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 will add 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 Input tab of an IATA PADIS Connector (with Translation Type set to XML-to-EDI) and select More > Create Test Files. XML files representing an Invoice, Purchase Order, Purchase Order Acknowledgment, and Shipping Notice will be automatically generated and placed in the Input directory. After these test files are processed by the connector, navigate to the Output tab to see the resulting PADIS document.