Nav

EDIFACT EDI Connector

Premium

The EDIFACT EDI connector lets you convert EDIFACT messages to and from DataWeave-compatible representations using lists and maps. This connector supports EDIFACT versions D.93A, D.95B, D.96A, D.97A, D.98B, D.99A, D.99B, D.00A, D.01B, D.02A, D.03A with supplied schema definitions for all standard messages.

Prerequisites

This document assumes that you are familiar with EDIFACT, Mule, Anypoint Connectors, Anypoint Studio, Mule flows, and Mule Global Elements.

See the Release Notes for compatibility information. A link to the release notes is listed in the See Also section of this document.

To use the EDIFACT EDI connector in a production environment, you must have purchased a MuleSoft license for Anypoint B2B.

What’s New in this Connector

EDIFACT EDI connector 2.x makes several changes to the configuration and handling over what was implemented by EDIFACT EDI connector 1.x:

  • EDIFACT EDI connector 1.x only supported messages from a single version of the standard. Mule 4 EDIFACT EDI connector 2.x supports messages from multiple versions of the standards. The version information in the message header (UNH segment) data is used to identify the standard version, and the message identifier determines the particular schema.

  • Identification parameters are no longer used for the read and write operations. You can configure all parameter values in the actual message data passed to the write operation.

  • All messages being written are checked for errors before any data is written to the output stream.

  • The undocumented "default" schema configuration for EDIFACT EDI connector 1.x is now officially supported by EDIFACT EDI connector 2.x. If no schemas are referenced in the configuration, the standard version of the schema for each message is looked up from the classpath and used for reading and writing. When this is done, no metadata is available for the message data structure, since the actual messages are unknown at design time.

To Install this Connector in Anypoint Studio 7

  1. In Anypoint Studio, click the Exchange icon in the Studio task bar.

  2. Click Login in Anypoint Exchange.

  3. Search for the connector and click Install.

  4. Follow the prompts to install the connector.

When Studio has an update, a message displays in the lower right corner, which you can click to install the update.

You must change the default Anypoint configuration to use the EDIFACT EDI connector 2.0.0.

To Create Schemas

If your implementation conventions differ from the standard, you can create schemas to describe your messages according to your implementation. Standard versions of the schemas for all defined EDIFACT messages and supported versions are included in the distribution.

About the EDI Schema Language

The EDIFACT EDI Module uses a YAML format called ESL (for EDI Schema Language) to represent EDI schemas. Basic ESLs define the structure of EDI messages in terms of structures (messages, in EDIFACT terminology), groups, segments, composites, and elements. ESLs for the EDIFACT versions d00a, d01b, d02a, d03a, d93a, d95b, d96a, d97a, d98b, d99a, and d99b are included.

You can customize the EDIFACT schema definitions to suit your data by defining an overlay schema. An overlay schema is a special form of ESL that allows 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 own schemas from scratch, or copy and edit a base EDIFACT schema definition to suit your data. See the EDI Schema Language Reference for more details.

YAML uses a combination of lists and sets of key-value pairs. The order of values is not important, as long as the required items are present. Quotes (either single or double quotes) are used around values that may consist of digits but are meant to be interpreted as strings (since otherwise the YAML parser treats the values as numbers). Indentation is used to show the nesting of lists.

For readability, the ESL structures shown here define all simple key-value pairs before any lists that are part of the same definition.

To Define your Implementation Convention with an Overlay Schema

To specify a schema according to your implementation convention, you can follow this process:

  1. Create an overlay schema that imports the base schema you want to customize - for example, EDIFACT 005010 850.

  2. Customize the overall structure for segment usage, positions, groups, and counts.

  3. Customize segments, including usage and counts.

Overlay schemas are very similar in structure to a complete schema definition, but instead of providing all the details of the schema structure they only list changes. Overlay schemas specify how to use implementation conventions with a particular trading partner to extend and customize the standard.

The following example provides the start of a sample overlay schema that modifies the basic EDIFACT D.98B ORDERS message definition. This example customizes the PAI segment and specifies that it is unused, thereby ensuring it is hidden from the mapping structures in Anypoint Studio.


          
       
1
2
3
4
5
6
7
8
form: EDIFACT
version: 'd98b'
imports: [ '/edifact/d98b/ORDERS.esl' ]
structures:
- idRef: 'ORDERS'
  name: Purchase Order
  heading:
  - { idRef: 'PAI', position: '0040', usage: U }

Structure Overlay

A structure overlay details modifications to the base schema definition of an EDIFACT message. Most often these modifications take the form of marking segments or groups in the base definition as unused, but any usage or repetition count change is allowed.

The following is the form taken by a structure overlay:


          
       
1
2
3
4
5
6
7
8
9
10
- idRef: 'ORDERS'
  heading:
  - { idRef: 'PAI', position: '0040', usage: U }
  - { idRef: 'IMD', position: '0060', usage: U }
  - groupIdRef: 'Segment group 15'
    position: '0560'
    items:
    - { idRef: 'HAN', position: '0570', usage: U }
    - { idRef: 'MEA', position: '0580', usage: U }
    - { idRef: 'FTX', position: '0590', usage: U }

The modifications in this example specify that the PAI and IMD segments of the standard ORDERS heading are not being used, along with the selected segments in Segment group 15.

The key-value pairs at the structure level are:

Key Description

idRef

The ID for the message being modified.

name

The message name (optional).

heading, detail, summary

List of segment and group modifications within each section of the structure. These are optional, and each is only used when there are modifications to that section.

The lists of segment modifications for the different sections of the structure (heading, detail, summary) all use the same structure. Each item in the list is either a segment reference or a group definition. Segment references are shown using a compact YAML syntax where the values for each reference are given as comma-separated key-value pairs enclosed in curly braces.

The values are:

Key Description

idRef

The referenced segment ID. This is optional and verified if provided, but otherwise ignored. The position value is used to uniquely identify segments within the section.

position

The segment position within the message section.

usage

Usage code, which may be M for Mandatory, O for Optional, C for Conditional, or U for Unused.

count

Maximum repetition count value, which may be a number or the special value >1 meaning any number of repeats. The count value is optional and a base definition value is used if a value is not specified.

Group overlays are shown in expanded form, with key-value pairs on separate lines.

The values in a group definition are:

Key Description

groupIdRef

The referenced group ID. This key is optional and verified if provided, but otherwise ignored. The position value is used to uniquely identify a group within a section.

position

The segment position within the message section.

usage

Usage code, which may be M for Mandatory, O for Optional, C for Conditional, or U for Unused.

count

Maximum repetition count value, which may be a number or the special value >1 meaning any number of repeats. The count value is optional and a base definition value is used if a value is not specified.

items

List of segments (and potentially nested group) making up the group.

Segment Overlays

A segment overlay details modifications to the base schema definition. Most often these modifications take the form of marking elements or composites in the base definition as unused, but any usage or repetition count change is allowed.

Example segment overlays:


          
       
1
2
3
4
5
6
7
8
9
10
segments:
- { idRef: FTX, trim: 20 }
- idRef: LIN
  items:
  - { position: 40, usage: U }
- { idRef: ALC, trim: 30 }
- idRef: PCI
  items:
  - { position: 20, usage: U }
  - { position: 40, usage: U }

The above example uses the compact form for segment modifications that only involves a truncation, while modifications that make changes to individual values are expressed in expanded form. As with all the other YAML examples, the two forms are actually equivalent and can be used interchangeably.

The key-value pairs in a segment overlay are:

Key Description

idRef

Segment identifier.

trim

Trim position in segment, meaning all values from this point on are marked as unused (optional).

items

List of individual value modifications.

The items list references values in the segment by position. The values for these references are:

Key Description

position

The value position within the segment.

name

The name of the value in the segment (optional, base definition value used if not specified).

usage

Usage code, which may be M for Mandatory, O for Optional, C for Conditional, or U for Unused.

count

Maximum repetition count value, which may be any number or the special value >1 meaning any number of repeats. The count value is optional and a base definition value is used if a value is not specified.

To Determine the EDIFACT Schema Location

To use the connector, you need to know the locations of the schemas in your project. If you’re using out-of-the-box EDIFACT schemas and not customizing anything, the schema location follows the /edifact/{version}/{message}.esl pattern, so for 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, you should put these under src/main/resources and refer to the location relative to this directory. For example, if you’ve put your ORDERS schema (either overlay or full) at src/main/resources/mypartner/ORDERS.esl, your schema location is `/mypartner/ORDERS.esl.

To Create a Mule Project in Anypoint Studio 7

After you install the connector and customize your schemas (if needed), you can start using the connector. Create separate configurations for each implementation convention.

  1. Click the Global Elements tab at the base of the canvas, and click Create.

  2. In the Choose Global Type wizard, locate and select the EDIFACT EDI: Configuration, and click OK.

  3. Click OK to save the global connector configurations.

  4. Return to the Message Flow tab in Studio.

Set each tab in the Global Element Properties as described in the sections that follow.

About the General Tab

General tab properties

The general tab lets you configure settings for reading and writing EDIFACT messages:

  • Manually create or edit the list of schema definitions for the message structures to be used.

  • String substitution character, used to replace invalid characters in string data.

  • Separators usage, whether specified values are to be used as defaults only for writes or also for reads.

  • Default data element separator character.

  • Default component element separator character.

  • Default repetition separator character.

  • Default segment terminator character.

  • Default release character.

About the Identity Tab

Identity tab properties

The Identity tab lets you configure the Interchange Header (UNB) identifier values for you and your trading partner in the EDIFACT EDI connector configuration. All these values are optional. If any are configured, the values are verified when reading an input message and used as the defaults when writing an output message if no value is specified in the output data.

The values that can be set are the Interchange ID qualifier and Interchange ID for your Mule application and partner. The Mule values specify the Receiver fields (UNB3.1/UNB3.2) in a receive message, and populate the Sender fields (UNB2.1/UNB2.2) fields in a send message.

About the Parser Tab

Parser tab properties

You can set the following options to control parser validation of receive messages if needed:

  • Enforce minimum and maximum lengths for receive values.

  • Enforce repetition count limits for receive values.

  • Enforce valid characters for UNOA/UNOB syntax levels.

  • Allow unknown segments in a message.

  • Enforce segment order in a message.

  • Allow segments marked as 'Unused' in a message.

  • Enforce segment repetition count limits in a message.

Other parser options let you:

  • Override character encoding for receive messages.

  • Require unique Interchange Control References (UNB.5).

  • Require globally unique Message Reference Numbers (UNH.1).

  • Set the minimum number of days to store interchange and message numbers for checking uniqueness.

About the Writer Tab

Writer tab properties

Settings for writing messages:

  • Set character encoding used for writing messages. The encoding must be defined in EDIFACT syntax versions.

  • Set syntax version (UNB1.2).

  • Enable a line ending that’s written between segments to make output more readable.

  • Always send UNA service segment (normally only sent when using non-standard separator characters).

  • Enforce valid characters for UNOA and UNOB syntax levels.

  • Request acknowledgments for send interchanges using Acknowledgment Request field (UNB.9).

  • Set a test indicator digit to be used on send interchanges (UNB.11).

Example: EDIFACT Studio

The following flow can be loaded in the XML for a project.

Mapping Flow Diagram


         
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns:edifact="http://www.mulesoft.org/schema/mule/edifact"
xmlns:http="http://www.mulesoft.org/schema/mule/http"
xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.mulesoft.org/schema/mule/core
http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http
http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd
http://www.mulesoft.org/schema/mule/edifact
http://www.mulesoft.org/schema/mule/edifact/current/mule-edifact.xsd
http://www.mulesoft.org/schema/mule/ee/core
http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd">
  <http:listener-config name="HTTP_Listener_config" doc:name="HTTP Listener config">
    <http:listener-connection host="localhost" port="8081" />
  </http:listener-config>
  <edifact:config name="EDIFACT_EDI_Config" doc:name="EDIFACT EDI Config"
    interchangeIdSelf="mule"
    interchangeIdQualifierSelf="ZZZ"
    interchangeIdPartner="partner"
    interchangeIdQualifierPartner="ZZZ">
    <edifact:schemas>
      <edifact:schema value="/edifact/d96a/ORDERS.esl"/>
      <edifact:schema value="/edifact/d99b/CUSRES.esl"/>
    </edifact:schemas>
  </edifact:config>
  <flow name="edifactmappingFlow">
     <http:listener doc:name="Listener" config-ref="HTTP_Listener_config" path="/map" />
     <edifact:read doc:name="Read" config-ref="EDIFACT_EDI_Config"/>
     <ee:transform doc:name="Transform Message">
       <ee:message >
         <ee:set-payload ><![CDATA[%dw 2.0
output application/java
---
{
    Messages: {
        D96A: {
            ORDERS: payload.Messages.D96A.ORDERS
        }
    }
}]]></ee:set-payload>
       </ee:message>
     </ee:transform>
     <edifact:write doc:name="Write" config-ref="EDIFACT_EDI_Config"/>
  </flow>
</mule>

Configuration Options in XML

All values listed in the Studio configuration can be set directly in XML.

General parameters control both send and receive document handling (all are optional, with default values as shown):

XML Value Visual Studio Option

schemas=list of values

List of paths for schemas to be used by connector. The paths may be either for a file system or classpath.

stringSubstitutionChar

Substitution character used to replace invalid characters in string values when using syntax level UNOA or UNOB.

separatorUsage="USE_DEFAULTS" "USE_SPECIFIED_FOR_WRITES" "USE_SPECIFIED_FOR_ALL"

Usage of specified separator/release characters as defaults for messages.

dataSeparator="+"

Data element separator character.

componentSeparator=":"

Component element separator character.

repetitionSeparator="*"

Repetition separator character.

segmentTerminator="'"

Segment terminator character.

releaseCharacter="?"

Release character.

Self identification parameters optionally identify your side of the trading partner relationship:

XML Value Visual Studio Option

interchangeIdSelf

Mule interchange sender/receiver ID (UNB2.1/UNB3.1).

interchangeIdQualifierSelf

Interchange sender/receiver ID qualifier (UNB2.2/UNB3.2).

Partner identification parameters optionally identify your partner:

XML Value Visual Studio Option

interchangeIdPartner

Partner interchange sender/receiver ID for Mule application (UNB2.1/UNB3.1).

interchangeIdQualifierPartner

Partner interchange sender/receiver ID qualifier (UNB2.2/UNB3.2).

Parser parameters control the parser operation and the types of error conditions which cause receive messages to be rejected (all are optional, with default values as shown):

XML Value Visual Studio Option

enforceLengthLimits="true"

Enforce minimum and maximum lengths for receive values.

enforceValueRepeats="true"

Enforce repetition count limits for receive values.

enforceReadCharacters="true"

Enforce valid characters for read (only applies when using syntax levels UNOA and UNOB).

allowUnknownSegments="false"

Allow unknown segments in a messaget.

enforceSegmentOrder="true"

Enforce segment order in a message.

allowUnusedSegments="false"

Allow segments marked as 'Unused' in a message.

enforceSegmentRepeats="true"

Enforce segment repetition count limits in a message.

receiveEncodingOverride="false"

Java character encoding to use for receive messages (overrides receive UNB).

requireUniqueInterchanges="true"

Require unique Interchange Control References (UNB.5)). The default behavior is to record the interchange numbers previously processed and reject any duplicate interchange numbers from the same partner (as determined by the interchange sender and receiver identification). If false, this instead allows processing of the received interchange to continue and leaves it to the application flow to track numbers and handle appropriately.

requireUniqueMessages="false"

Enforce globally unique Message Reference Numbers (UNH.1) for received messages. By default, message reference numbers only need to be unique with a particular interchange. If true, this instead requires message reference numbers to be unique across all interchanges received from the same partner and application (as determined by the interchange sender and recipient identification).

daysToStore="30"

Minimum number of days to store interchange, group, and message numbers for checking uniqueness.

Writer parameters control the writer operation (all are optional, with default values as shown):

XML Value Visual Studio Option

characterEncoding="ASCII_B"

Character encoding used for writing messages (which must be one defined in EDIFACT syntax versions).

sendSyntaxVersion="VERSION4"

Syntax version for send messages, also used to determine the data structures used for service segments and CONTRL acknowledgment message structures in DataSense metadata for both send and receive.

lineEnding="NONE" "LF" "CRLF" "CR"

Line ending to add between segments, which defaults to NONE. This allows you to add line endings between segments to improve the readability of the output message text.

alwaysSendUNA="false"

Always send UNA service segment. With the default setting of false, a UNA is only included in an interchange when the syntax separator characters don’t match the defaults for the syntax version and character encoding in use, if set to true, a UNA is always sent.

enforceWriteCharacters="true"

Enforce valid characters for write (only applies when using syntax levels UNOA and UNOB).

sendUniqueMessageNumbers="false"

Send unique Message Reference Numbers (UNH.1). By default, message reference numbers are assigned sequentially within each interchange and are reused in different interchange. If true, this instead assigns unique transaction set numbers across all interchanges sent to the same partner (as determined by the interchange sender and recipient identification).

initialInterchangeReference="1"

The initial Interchange Control Reference used for outgoing messages.

initialMessageReference="1"

The initial Message Reference Number used for outgoing messages.

requestAcks="false"

Request acknowledgments for send interchanges using the Acknowledgment Request field (UNB.9).

testIndicator=""

Test indicator digit to be used on send interchanges (UNB.11). By default, interchanges are not sent as tests.

To Set Your Schema Locations

You can configure schema locations in the Anypoint Studio XML view.

In Anypoint Studio, switch to the XML view by clicking Configuration XML and modify your EDIFACT EDI configuration to include a list of all the schemas you wish to include by adding an <http://edischema[edi:schema]> element for each document type:


         
      
1
2
3
4
5
<edifact-edi:config name="EDIFACT_EDI__Configuration" identKeys="true" doc:name="EDIFACT EDI: Configuration">
  <edifact-edi:schemas>
    <edifact:schema value="/edifact/d96a/ORDERS.esl"/>
  </edifact-edi:schemas>
</edifact-edi:config>

After you create a global element for your EDIFACT EDI, configure any schemas and operations.

About the EDIFACT Message Structure

The connector enables reading or writing of EDIFACT documents into or from the canonical EDI message structure. This structure is represented as a hierarchy of Java Maps and Lists, which can be manipulated using DataWeave or code. Each transaction has its own structure, as defined in the schemas, as outlined above.

The message itself contains the following keys (some of which only apply to either the read operation or the write operation, as indicated):

Key Name Description

Delimiters (optional)

The delimiters used for the message (set based on the last interchange processed by a read operation). If set for a write operation, this overrides the values in the module configuration. The characters in the string are interpreted based on position, 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 with the input as a whole, or with interchanges with no valid messages. See the EdifactError structure description in the To Read and Validate EDIFACT EDI Messages section below.

FunctionalAcksGenerated (read only)

A list of CONTRL acknowledgment messages that were generated by the module during the read operation. To send an acknowledgment, see the Sending Acknowledgments section below.

FunctionalAcksToSend (write only)

A list of CONTRL acknowledgment messages that are to be sent by the module during the write operation.

Interchange (write only)

Map of UNB interchange header segment values used as defaults when writing interchanges.

Messages

A hierarchy of the messages which were read by the module during a read operation, or which are to be 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 instance). For example, if you are using version D96.A ORDERS and CUSRES messages, the Messages would contain a map with one key, "D96A". The value of this key would be another map, this one with two keys, "ORDERS" and "CUSRES". Each of these would contain a list of individual ORDERS and CUSRES messages that you could then process.

Individual messages have their own maps, with the following keys:

Key Description

Detail

Map of segments or loops from the detail section of the message. Values are maps for segments or loops which occur at most once, lists of maps for values which may be repeated.

Errors (read only)

A list of errors associated with the message. (See the EdifactError class description in the Reading and Validating EDI Messages section below.)

Heading

Map of segments or loops from the heading section of the message. Values are maps for segments or loops which occur at most once. Lists of maps are used for values which may be repeated.

Id

Message ID, which must match the key of the containing message list.

Interchange

Map of UNB interchange header segment values. When reading a message, this map is the actual data from the enclosing interchange (a single map linked from all messages in the interchange). When writing a message, these values are used for creating the enclosing interchange (gathering messages with the same interchange values into a single interchange, regardless of whether the actual maps are the same or not). Values not populated in this map default to the values from the Interchange map at the message level.

MessageHeader

Map of UNH message header segment values. This gives the actual header data for a read operation, and allows you to provide overrides for configuration settings for a write operation.

Name

Message name.

Summary

Map of segments or loops from the summary section of the message. Values are maps for segments or loops which occur at most once. Lists of maps are used for values which may be repeated.

Generated CONTRL functional acknowledgment messages differ from received messages in their handling of interchange information:

Key name Description

Interchange

Map of UNB interchange header segment values. 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) interchanged. When writing a message, these values are used for creating the enclosing interchange (gathering messages with the same interchange values into a single interchange, regardless of whether the actual maps are the same or not). Values not populated in this map default to the values from the Interchange map at the message level.

To Read and Validate EDIFACT EDI Messages

  1. To read an EDIFACT message, search the palette for EDIFACT EDI, and drag the EDIFACT Read operation into a flow.

  2. Go to the properties view, select the connector configuration you created above and select the Read operation. This operation reads any byte stream into the structure described by your EDIFACT schemas.

The EDIFACT module validates the message when it reads it in. Message validation includes checking the syntax and content of envelope segments UNB and UNZ as well as the actual messages in the message. Normally errors are both logged and accumulated and reported in CONTRL acknowledgment messages, and all accepted messages (whether error free or with non-fatal errors) are passed on for processing as part of the output message Map. Errors in reading the input data results in exceptions being thrown.

Error data entered in the receive data map uses the EdifactError class, a read-only JavaBean with the following properties:

Property Description

segment

The zero-based index within the input of the segment causing the error.

fatal

Flag for a fatal error, meaning the associated message, group, or interchange was rejected as a result of the error.

errorCode

EDIFACT syntax error code.

errorText

Text description of the error.

Error data is returned by the read operation as optional lists with the "Errors" key at both root level of the data structure and at the message level. At the message level, this list contains non-fatal errors encountered during the parsing of that message. At the root level, this list contains both interchange errors and fatal message errors.

To Write EDIFACT EDI Messages

To write an outgoing message, search the palette for EDIFACT EDI and drag the EDIFACT Write operation into a flow. Construct an outgoing EDIFACT EDI message according to the structure as defined above for input to the write operation. If no fatal errors are found in the write operation the normal flow continues. Otherwise, an exception is thrown which describes the error.

To Send Functional Acknowledgments

Sending generated functional acknowledgments (CONTRL messages) is the same as writing any other EDI message, except you set the transactions to the acknowledgments that were generated during the read operation.

For example:

Ack Flow Diagram


         
      
1
2
3
4
5
6
7
8
9
10
11
<edifact-edi:read config-ref="EDIFACT_EDI__Configuration" doc:name="Read EDI Doc"/>
  ...
<dw:transform-message doc:name="Create Outgoing Acks Message">
    <dw:set-payload><![CDATA[%dw 1.0
%output application/java
---
{
        FunctionalAcksToSend: payload.FunctionalAcksGenerated
}]]></dw:set-payload>
</dw:transform-message>
<edifact-edi:write config-ref="EDIFACT_EDI__Configuration" doc:name="Send Acks"/>

The generated functional acknowledgments have interchange data set up for sending back to the sender of the original message, so you don’t need to change anything in the transactions to do the send.