EDIFACT encoder in Logic App escapes whitespaces in all string literal values

Question

EDIFACT encoder in Logic App escapes whitespaces in all string literal values

Strömberg Johannes 0

We have a couple of logic apps which outputs EDIFACT messages using the EDIFACT encoder but for some reason it's adamant in it's escaping of whitespaces in string literals. We have used schemas from BizTalk and we've set up the following in the integration account agreement:

Apply UNA Segment - Checked

Character Sets and Separators - UNB1.1 - UNOC

Parameter	Value
Input type	Blank (we tried "Char" but it didn't save that choice)
Component Separator	:
Data Element Separator	+
UNA3 (Decimal Notation)	Comma
UNA4 (Release Indicator)	?
UNA5 (Repetition Separator)	whitespace
Segment Terminator	'
Suffix	None

No validation is active

We've had this solution running in BizTalk 2020 for years now and it's been fine, but running it in a Logic App it has this escaping issue. Example:

Output from BizTalk:

STS+1+3::87:All Ok. Status is green'

Output from Logic Apps (same input file):

STS+1+3::87:All? Ok.? Status? is? green'

How can we get the same behavior in Logic Apps as we had in BizTalk (i.e stop it from escaping whitespaces in string literals)?

Rakesh Mishra 4,115 Reputation points Microsoft External Staff Moderator

2025-12-17T09:07:37.3233333+00:00

Hi @Strömberg Johannes , following up to see if you had a chance to check my previous response and if it was helpful. Please do let me know if you're still facing the issue and need any further assistance on this.
Siddhesh Desai 740 Reputation points Microsoft External Staff Moderator

2025-12-19T05:29:42.03+00:00

Hi @Strömberg Johannes

Did you get a chance to look at the Rakesh's response above? And Let us know if its helpful?

1 answer

Your answer

Rakesh Mishra 4,115 Reputation points Microsoft External Staff Moderator

2025-12-17T09:07:37.3233333+00:00

Hi @Strömberg Johannes , following up to see if you had a chance to check my previous response and if it was helpful. Please do let me know if you're still facing the issue and need any further assistance on this.
Siddhesh Desai 740 Reputation points Microsoft External Staff Moderator

2025-12-19T05:29:42.03+00:00

Hi @Strömberg Johannes

Did you get a chance to look at the Rakesh's response above? And Let us know if its helpful?

Answer 1

Rakesh Mishra 4,115 Microsoft External Staff Moderator

Hi @Strömberg Johannes ,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

Logic Apps is correctly inserting the EDIFACT release indicator (UNA4, your ?) before every character that your agreement declares as a separator (in your case you configured the repetition separator UNA5 as a whitespace). Because you told the encoder that the space is a separator, the encoder escapes spaces in data by prefixing them with the release indicator — which is exactly the All? Ok.? Status? is? green you see.

Please try below and share your findings.

Don’t use whitespace as the repetition separator (UNA5).
Reason: UNA5 is the repetition separator — if it’s set to a space, any space in a free-text data element is treated as a repetition separator and therefore must be escaped. Remove the whitespace value or choose a non-conflicting character (or leave UNA5 unset) so ordinary spaces are not treated as separators.
Only generate a UNA segment when you need non-standard separators. The docs say to use the UNA segment only if your interchange uses non-standard separator characters; if you don’t need a custom repetition separator, don’t set it / don’t apply UNA. This avoids making space a special character.
How to change it in the portal (where to click — per docs):
- Open your Integration Account → Agreements → edit the relevant agreement.
- Under the agreement’s Send / Character Sets and Separators section, change the UNA/Repetition Separator (UNA5) — either clear it (no char) or set a safe single character that will not appear in free-text. Save the agreement.
Test using the EDIFACT encode action (after changing agreement): use the Encode to EDIFACT message by agreement name action in your Logic App and verify output. The EDIFACT connector/encode action is documented in the Logic Apps EDIFACT guide.

If the trading partner requires a space as repetition separator

If the partner actually insists on a space as the repetition separator, you have two unpleasant choices (both non-standard and partner-specific):

Pre-escape or transform free-text content so it does not contain raw spaces (ugly and likely unacceptable), or
Agree with the partner to use a different repetition separator (recommended) so free text does not need escaping.

Strömberg Johannes 0 Reputation points

2025-12-12T10:55:34.89+00:00
Just so I get this straight, by the looks of things after digging around in various EDI implementations from big companies around the globe as well as going over the official specifications from UNECE and GS1 I've found this out:

UNECE defines UNA5 as "Reserved for future use" and it should have a whitespace.

GS1 in their EANCOM standard defines UNA5 as a data repetition separator (where the suggest an asterisk as the default value)

In all the documentation from the companies I've looked at, they all adhere to the UNECE standard as their base where they use the whitespace in UNA5 as basically not in use, but reserved for future use. And in the rest of their specifications whitespaces aren't escaped or released.

Does this mean the Azure is implementing GS1/EANCOM rather than UNECE standards?
And conversely, does this mean that Microsoft BizTalk Server is implementing UNECE standards and not GS1/EANCOM?

Just trying to wrap my head around why we have different outcomes from the different products although we use the same schemas.
Rakesh Mishra 4,115 Reputation points Microsoft External Staff Moderator

2025-12-16T13:17:00.67+00:00
Hi @Strömberg Johannes , your findings are correct, and the difference comes down to which document or explicit UNA settings each product respects:

UNECE / UN-EDIFACT: the UN spec treats the UNA service-position 5 as reserved / default space and historically reserves it for future use (i.e., the UNA need not be used when default service characters are in effect).

GS1 / EANCOM: the GS1 EANCOM profile defines UNA5 as the repetition separator (and documents a default repetition character such as * in their profile). In other words, EANCOM explicitly uses UNA5 for repetition-separator purposes.

Azure Logic Apps (EDIFACT encoder): Logic Apps exposes UNA5 as the Repetition Separator in the integration-account agreement settings and will treat whatever you configure there as the repetition separator during encode — so if you set UNA5 to a space, the encoder will treat space as a separator and therefore escape/“release” spaces in data. That behavior is driven by the explicit agreement setting.

BizTalk Server: BizTalk’s EDIFACT pipeline also supports UNA but the guidance there is to only generate/use a UNA segment when non-standard service characters are required. In practice BizTalk setups often rely on the default service characters (or strip/handle the UNA/release on receive), which explains why you’ve observed unescaped spaces from BizTalk even for the same schema.

Conclusion: you’re not seeing a standards contradiction so much as different profiles/assumptions. GS1/EANCOM is a profile that defines UNA5 as a repetition separator; UNECE leaves UNA5 as reserved/default space. Azure Logic Apps will honor the explicit UNA5 value you put in the agreement (so it behaves like an EANCOM-style profile if you set UNA5 to space or another char). BizTalk, when using default service characters or when it strips/handles the UNA on receive, will appear to produce “unescaped” spaces.

Recommendation: make the agreement settings explicit and consistent between systems (don’t set UNA5 to a literal space unless the partner truly requires that — prefer leaving UNA5 unset or use a non-space repetition separator such as * if EANCOM is expected). That will remove the behavioral mismatch.

Reference:

https://quic.hkg1.meaqua.org/en-us/azure/logic-apps/logic-apps-enterprise-integration-edifact-message-settings

https://quic.hkg1.meaqua.org/en-us/biztalk/core/configuring-charset-and-separators-edifact
Strömberg Johannes 0 Reputation points

2025-12-17T09:47:40.8166667+00:00

Hi Rakesh. I see your points here, our main problem is that in our BizTalk server environment with all the integrations we have there most of our partners expect the UNA segment in the EDI communications even if it's standard definitions in there. Many of these integrations have been running in production since BizTalk Server 2006 so we're closing in on 20 years now and having all of them change their expectations based on us moving to Azure Logic Apps might be a hard pill to swallow.

Is there any recommended way to include the UNA segment and still have the same behavior as in BizTalk Server when it comes to this issue or do we simply have to resort to do string processing after generating the EDIFACT data?

Rakesh Mishra 4,115 Microsoft External Staff Moderator

Hi @Strömberg Johannes , below could be the possible solution. Please try it once and let me know how it goes. Please note that I have taken help of AI systems to generate sample code. Please make sure to test it first before introducing any major changes.

Add an Inline Code action in Logic Apps (JS) named e.g. SanitizeReleaseBeforeRepetition.
Pass the encoded message as input and optionally the releaseChar and repetitionChar (default to ? and space).

JS logic (drop into Inline Code):

  // inputs: { payload, releaseChar, repetitionChar }
  const payload = inputs.payload || "";
  const releaseChar = (inputs.releaseChar || "?");
  const repetitionChar = (inputs.repetitionChar || " ");
  // escape regex helper
  function esc(s) { return s.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'); }
  // Parse UNA (if present) to get separators, otherwise use defaults
  let data = payload;
  let sep = {
    component: ':',
    element: '+',
    decimal: '.',
    release: releaseChar,
    repetition: repetitionChar,
    segmentTerm: "'"
  };
  const unaMatch = payload.match(/^UNA(.{6})/);
  if (unaMatch) {
    const u = unaMatch[1];
    sep.component = u[0] || sep.component;
    sep.element   = u[1] || sep.element;
    sep.decimal   = u[2] || sep.decimal;
    sep.release   = u[3] || sep.release;
    sep.repetition= u[4] || sep.repetition;
    sep.segmentTerm = u[5] || sep.segmentTerm;
    // Keep UNA unchanged; data after UNA follows parsed separators
  }
  // Split by segment terminator (keep empty trailing segment handling)
  const segTermEsc = esc(sep.segmentTerm);
  const segRegex = new RegExp(segTermEsc, 'g');
  const segments = data.split(sep.segmentTerm);
  // Process each segment except UNA
  for (let i=0;i<segments.length;i++){
    const seg = segments[i];
    if (!seg) continue;
    if (seg.startsWith('UNA')) continue; // leave UNA as-is
    // split into elements by element separator
    const elements = seg.split(sep.element);
    for (let j=0;j<elements.length;j++){
      // remove only releaseChar that immediately precedes repetitionChar
      // build regex like /\? /g but safely escaped
      const pattern = new RegExp(esc(sep.release) + esc(sep.repetition), 'g');
      elements[j] = elements[j].replace(pattern, sep.repetition);
    }
    segments[i] = elements.join(sep.element);
  }
  // rejoin with segment terminator
  let result = segments.join(sep.segmentTerm);
  // if original payload had terminating segmentTerm, preserve it
  if (payload.endsWith(sep.segmentTerm)) result += sep.segmentTerm;
  return { sanitized: result };

Note: this only removes release indicators that immediately precede the repetition separator. It preserves UNA and all other release sequences.

Share via

EDIFACT encoder in Logic App escapes whitespaces in all string literal values

1 answer

If the trading partner requires a space as repetition separator

Your answer