- 9 minutes to read

EDIMessageTypeParseString – System Parameter

Control how Nodinite automatically names EDIFACT messages with the EDIMessageTypeParseString system parameter. This pattern template determines how Message Types are identified from EDI message headers.

What you'll achieve with this parameter:

  • Automatically extract Message Type names from EDIFACT UNH segments
  • Customize Message Type naming conventions for your EDI standards
  • Enable precise Search Field extraction for EDI messages
  • Maintain consistent Message Type naming across all EDIFACT integrations

The EDIMessageTypeParseString System Parameter defines a pattern template used by the Nodinite Logging Service to automatically determine the Message Type name for EDIFACT (Electronic Data Interchange For Administration, Commerce and Transport) messages by parsing the UNH (Message Header) segment.

System Parameter Name Data Type Default Value Comment
EDIMessageTypeParseString string {MessageType}.{MessageVersionNumber}{MessageReleaseNumber}{ControllingAgencyCoded} Pattern template with 8 available variables. Changes apply to newly logged messages.

Note

Changes to this parameter take effect immediately for the Logging Service. You do NOT need to restart any services. However, changes only affect newly logged messages—existing messages retain their original Message Type names.

How It Works

EDIFACT UNH Segment Structure

EDIFACT messages contain a UNH (Message Header) segment that identifies the message type and version. The Logging Service parses this segment and uses the EDIMessageTypeParseString pattern to construct the Message Type name.

Example UNH Segment:

UNH+1+ORDERS:D:96A:UN:EAN008'

This segment contains:

  • Message Reference Number: 1
  • Message Type: ORDERS
  • Message Version Number: D
  • Message Release Number: 96A
  • Controlling Agency: UN
  • Association Assigned Code: EAN008

Pattern Variables

The pattern template supports 8 variables extracted from the UNH segment:

Variable UNH Position Example Value Description
{MessageReferenceNumber} UNH010 1 Message reference number (usually sequential)
{MessageType} UNH020 ORDERS Message type identifier (ORDERS, DESADV, INVOIC, etc.)
{MessageVersionNumber} UNH030 D Version number (D = Draft, S = Standard)
{MessageReleaseNumber} UNH040 96A Release number (e.g., 96A, 01B, D12A)
{ControllingAgencyCoded} UNH050 UN Controlling agency (UN = UN/CEFACT, X12 = ASC X12)
{AssociationAssignedCode} UNH060 EAN008 Association-specific code (optional)
{CodeListDirectoryVersionNumber} UNH070 8 Code list directory version (optional)
{MessageTypeSubFunctionIdentification} UNH080 1 Sub-function identification (optional)

Default Pattern Example

Default Pattern:

{MessageType}.{MessageVersionNumber}{MessageReleaseNumber}{ControllingAgencyCoded}

UNH Segment:

UNH+1+ORDERS:D:96A:UN:EAN008'

Resulting Message Type:

ORDERS.D96AUN

This becomes the Message Type name stored in Nodinite for the logged EDIFACT message.

Configuration Examples

Example 1: Include Association Code

Pattern:

{MessageType}.{MessageVersionNumber}{MessageReleaseNumber}.{AssociationAssignedCode}

UNH Segment:

UNH+1+DESADV:D:01B:UN:EAN008'

Resulting Message Type:

DESADV.D01B.EAN008

Use Case: When different industry associations (EAN, EANCOM, EDIFACT) use the same base message type but with industry-specific variations.

Example 2: Simplified Pattern (Message Type Only)

Pattern:

EDIFACT.{MessageType}

UNH Segment:

UNH+1+INVOIC:D:96A:UN'

Resulting Message Type:

EDIFACT.INVOIC

Use Case: When you want to group all versions of a message type together, ignoring version/release differences.

Example 3: Full Detail Pattern

Pattern:

{MessageType}.{MessageVersionNumber}{MessageReleaseNumber}{ControllingAgencyCoded}.{AssociationAssignedCode}

UNH Segment:

UNH+1+ORDERS:D:96A:UN:EAN008'

Resulting Message Type:

ORDERS.D96AUN.EAN008

Use Case: Maximum detail for environments with multiple EDI standards and industry-specific variations.

Example 4: Message Type with Release Only

Pattern:

{MessageType}.{MessageReleaseNumber}

UNH Segment:

UNH+1+DESADV:D:96A:UN'

Resulting Message Type:

DESADV.96A

Use Case: Simplified naming when you only care about the release version, not the draft/standard indicator or controlling agency.

When to Change This Parameter

Most organizations should keep the default pattern because:

Industry Standard - Matches common EDIFACT naming conventions
Precise Identification - Distinguishes between message versions and releases
Search Field Binding - Enables version-specific Search Field Expressions
Compatibility - Works with most EDI partners and standards

Consider Changing When

Simplified Naming Needed - You want to group all versions together (e.g., EDIFACT.ORDERS)
Industry-Specific Requirements - Your industry requires association codes (e.g., ORDERS.D96A.EAN008)
Organizational Standards - Company policy mandates specific Message Type naming
Partner Requirements - Trading partners expect specific naming conventions

Impact on Message Types and Search Fields

Message Type Creation

When the Logging Service processes EDIFACT messages:

  1. Parse UNH Segment - Extract values from the message header
  2. Apply Pattern - Use EDIMessageTypeParseString to construct Message Type name
  3. Store Message Type - Save to Message Types in Configuration Database
  4. Bind Log Event - Associate the logged message with the Message Type

This automatic extraction means you don't need to manually create Message Types for EDIFACT messages—they're created on-the-fly as messages are logged.

Search Field Expressions

The Message Type name determines which Search Field Expressions are applied:

  • Version-Specific Expressions - With default pattern, you can have different RegEx expressions for ORDERS.D96AUN vs ORDERS.D01BUN
  • Grouped Expressions - With simplified pattern EDIFACT.ORDERS, one expression applies to all ORDERS versions
  • Testing & Debugging - Use the Test Expression feature with your actual Message Type names

Tip

After changing this parameter, test with a sample EDIFACT message to verify the resulting Message Type name matches your expectations before deploying to production.

Best Practices

Pattern Design

Keep It Readable - Avoid overly complex patterns with too many variables
Balance Detail vs Simplicity - Include enough detail to distinguish versions, but not so much it's confusing
Test with Real Data - Validate your pattern with actual UNH segments from your EDI partners
Document Your Choice - Record why you chose a specific pattern for future reference

Migration Planning

If you need to change the pattern after production use:

  1. Plan Timing - Change during low-traffic period
  2. Consider History - Old messages keep old Message Type names (no automatic rename)
  3. Update Search Fields - Modify Search Field Expressions to work with new Message Type names
  4. Re-Index If Needed - Use Message Type re-indexing to apply new names to historical messages (optional)
  5. Test Thoroughly - Verify Log Views and Search Fields work with new naming

Caution

Changing this parameter does NOT rename existing Message Types. Historical messages retain their original Message Type names. Only newly logged messages use the new pattern.

Integration with Repository Model

The Message Type names created by this parameter integrate throughout the Nodinite Repository Model:

  • Services - EDIFACT Message Types are organized within Services
  • Transport Contracts - Combine Message Types with Endpoints for log point definitions
  • Log Views - Filter messages by auto-created EDIFACT Message Type
  • Stylesheets - Display EDIFACT messages with Message Type-specific formatting
  • Search Field Expressions - Bind RegEx extraction to specific EDIFACT versions

This integration ensures your EDI messages are properly tracked, searchable, and correlated across the entire integration landscape.

Frequently Asked Questions

Find more solutions and answers in the Nodinite System Parameters FAQ, as well as the Troubleshooting user guide.

How do I change the value?

Changing a value for the pre-defined System Parameters is described in the generic 'How do I change the System Parameters' article.

Via Admin UI:

  1. Navigate to Administration → Settings → System Parameters
  2. Find EDIMessageTypeParseString
  3. Update the pattern template (use variables from the table above)
  4. Click Save
  5. Changes take effect immediately for newly logged messages

Do I need to restart anything?

No! Changes to this parameter take effect immediately in the Logging Service. You do NOT need to restart any services. However, the new pattern only applies to newly logged messages—existing messages keep their original Message Type names.

What happens to existing Message Types when I change the pattern?

Existing Message Types and their associated logged messages are not affected. The new pattern only applies to EDIFACT messages logged after the change. This means:

  • Historical messages retain their original Message Type names
  • New messages use the new pattern
  • You may temporarily have two Message Types for the same EDIFACT message (old pattern and new pattern)

To consolidate, you can use the Message Type re-indexing feature to apply the new pattern retroactively (optional).

Does this parameter affect X12 or other EDI standards?

No. This parameter only affects EDIFACT messages (those with UNH segments). Other EDI standards are handled differently:

  • X12 - Uses ISA/GS segment parsing (different logic)
  • Custom EDI - Uses Context Options or manual Message Type specification
  • TRADACOMS - Uses STX segment parsing (different logic)

Can I use literal text in the pattern?

Yes! You can combine variables with literal text:

EDIFACT.{MessageType}.{MessageReleaseNumber}

Results in: EDIFACT.ORDERS.96A

Or:

{MessageType}_v{MessageReleaseNumber}_{ControllingAgencyCoded}

Results in: ORDERS_v96A_UN

What if a UNH segment is missing a variable I'm using?

If the UNH segment doesn't contain a value for a variable in your pattern (e.g., {AssociationAssignedCode} is empty), the variable is replaced with an empty string:

Pattern: {MessageType}.{MessageReleaseNumber}.{AssociationAssignedCode}
UNH: UNH+1+ORDERS:D:96A:UN' (no association code)
Result: ORDERS.96A. (note the trailing period)

To avoid this, only include variables that are consistently present in your EDI messages.

How do I test a new pattern before deploying?

  1. Non-Production Environment - Test in Dev/QA first
  2. Sample Message - Send a test EDIFACT message
  3. Check Message Type - View the logged message in a Log View and verify the Message Type name
  4. Validate Format - Ensure the name is readable and matches expectations
  5. Deploy to Production - Once validated, update the production parameter

Does changing this affect Search Field extraction?

Yes, indirectly. Search Field Expressions are bound to specific Message Types. If you change the naming pattern:

  1. New Message Type names are created (e.g., ORDERS.D96AUN becomes ORDERS.96A)
  2. Existing Search Field Expressions remain bound to the old Message Type names
  3. You must update Search Field Expressions to also target the new Message Type names
  4. Alternatively, use the Message Type re-indexing feature to rename historical messages

Next Step

Message Types - Understand Message Type concepts
Add or manage Message Type - View and manage auto-created EDIFACT Message Types
Search Field Expressions - Bind RegEx expressions to EDIFACT Message Types
Logging Service - Learn how messages are processed