EDIFACT EDI Connector 2.10 | MuleSoft Documentation
# EDIFACT EDI Connector 2.10
Anypoint Connector for EDIFACT EDI (EDIFACT Connector) enables you to convert EDIFACT messages to and from DataWeave-compatible representations using lists and maps.
You can check the supported EDIFACT versions for supplied schema definitions for all standard messages.
## Before You Begin
To use this connector, you must be familiar with:
  * Anypoint Connectors
  * Mule runtime engine (Mule)
  * Elements and global elements in a Mule flow
  * Creating a Mule app using Anypoint Studio (Studio)


To use EDIFACT EDI Connector, you must have:
  * A MuleSoft license for Anypoint B2B
  * Anypoint Studio 7.0 or later


EDIFACT Connector supports files of up to 15 MB in size, and the memory requirement is approximately 40 to 1. For example, a 1-MB file requires up to 40 MB of memory to process, so it’s important to consider this memory requirement in conjunction with your Transactions Per Second (TPS) needs for large X12 files. This is not an exact figure; the value varies according to the complexity of the mapping instructions.   
---  
### Understanding the EDI Schema Language
The EDIFACT EDI Connector uses a YAML format called EDI Schema Language (ESL) to represent EDI schemas. Basic ESLs define the structure of EDI messages in terms of:
  * Structures, known as messages, in EDIFACT terminology
  * Groups, segments, composites, and elements


You can customize the EDIFACT schema definitions to suit your data by defining an _overlay schema_. An _overlay schema_ is a type of ESL that enables you to modify a base schema, such as an EDIFACT D.98B ORDERS schema, with your specific conventions. You don’t need an _overlay schema_ if you’re using the structure defined by the standard, but most EDI exchanges modify the base definitions in an implementation convention.
You can also define your schemas, or copy and edit a base EDIFACT schema definition to suit your data as shown in the EDI Schema Language Reference.
## Finding Schema Locations
To use the connector, you need to know the locations of the schemas in your project. If you’re using base EDIFACT schemas and not customizing anything, the schema location follows the `/edifact/{version}/{message}.esl` convention. For example, using the D.98B version of the ORDERS message, your schema location is `/edifact/d98b/ORDERS.esl`.
If you’re using one or more custom schemas, place these in the `src/main/resources` directory and refer to the location relative to this directory. For example, if you’ve put your ORDERS schema (either overlay or full) in `src/main/resources/mypartner/ORDERS.esl`, your schema location is `/mypartner/ORDERS.esl`.
## The Hierarchy of EDIFACT Connector Message Structure
Use this connector to read or write EDIFACT documents in (or from) the canonical EDI message structure. This structure is a hierarchy of Java Map and List objects. You use either DataWeave or code to manipulate them. Each transaction has its own structure as defined in the schemas.
The message contains the following keys, some of which apply to either the Read operation or the Write operation, as indicated:
Key Name | Description  
---|---  
Delimiters | An optional set of delimiters used in the message. If used in a Read operation, the delimiters are based on the most recent interchange processed by a Read operation. If used for a Write operation, the delimiters override the values in the module configuration. The characters in the string of delimiters are interpreted based on their position in string, in the following order: data element separator, component element separator, repetition separator, segment terminator, release character.  
Errors (read only) | A list of errors that are associated either with the input as a whole or with interchanges that have no valid transaction sets.  
FunctionalAcksGenerated (read only) | A list of `CONTRL` acknowledgments that are generated by the module during the Read operation.  
FunctionalAcksToSend (write only) | A list of `CONTRL` acknowledgments that are sent by the module during the Write operation.  
Interchange (write only) | Map of UNB interchange header segment values used as defaults during an interchange Write operation.  
Messages | A hierarchy of messages that are either read by the module during a Read operation or sent by the module during a Write operation. The value of this top-level key is a map with standard versions as keys, in the form `D96A`. For example, if you are using version `D96.A ORDERS` and `CUSRES` messages, the Messages contain a map with one key, `D96A`. The value of this key is another map, one with two keys, `ORDERS` and `CUSRES`. Each of these contains a list of individual ORDERS and CUSRES messages that are processed.  
Individual messages have their own maps, with the following keys:
Key | Description  
---|---  
Map of segments or loops from the detail section of the message. Values are maps for segments or loops that occur once. Lists of maps are for values that occur more than once.  
Errors (read only) | A list of errors associated with the message.  
A map of segments or loops from the heading section of the message. Values are maps for segments or loops that occur once. Lists of maps exist for values that occur more than once.  
The Message ID must match the key of the containing message list.  
Interchange | A map of UNB interchange header segment values. For a Read message, the map is the actual data from the enclosing interchange. It is a single map linked from all messages in the interchange. For a Write message, the map value creates the enclosing interchange. For example, gathering messages with the same interchange values into a single interchange, regardless of whether the actual maps are the same. If there are no values for this map, then the default is the value taken from the Interchange map at the message level.  
A map that contains the UNG group header segment values:
  * For a read message, the map consists of data from the enclosing group. The map is a single map linked from all transaction sets in the group.
  * For a write message, the map value creates the enclosing group. If there are no values for the map, it consists of values taken from the group map at the message level by default.

  
MessageHeader | Map of UNH message header segment values. This provides the actual header data for a Read operation, and enables you to provide overrides for Write operation configuration settings.  
Message name  
Map of segments or loops from the summary section of the message. Values are maps for segments or loops that occur once. Lists of maps are for values that occur more than once.  
Generated CONTRL functional acknowledgment messages differ from Received messages in their handling of interchange information:
Key name | Description  
---|---  
Interchange | For functional acknowledgments generated by Receive processing, this map is a copy of the data for the containing interchange with Sender and Receiver identification components (UNB2.1/UNB2.2 and UNB2.1/UNB3.2). For a Write message, these values are used for creating the enclosing interchange. For example, messages are gathered with the same interchange values into a single interchange, regardless of whether the actual maps are the same. If there are no values for this map, then the default is the value taken from the Interchange map at the message level.  
## Next Step
After you complete the prerequisites, you are ready to create your own app and configure the connector using Anypoint Studio.
## See Also
MuleSoft Help Center