About Templates

About Templates¶

Templates are the blueprint that enables FeedXChange to understand, validate, and process data files. They serve as the translation layer between your source system's file format and ReactorCX's data processing capabilities.

Template Fundamentals¶

A template defines:

File structure - Layout, format, and organization of input and response files
Field definitions - Data types, lengths, validation rules, and transformation logic
Processing rules - How data is validated, transformed, and handled
Response generation - What information to return to the source system

Templates are partner-specific and RCX process-specific, ensuring that each data integration is precisely configured for its intended purpose.

Note

Regular expression patterns are used throughout the ReactorCX platform for file filtering, header matching, body matching, and so on. A regular expression (often abbreviated as regex or regexp) is a sequence of characters that defines a search pattern. You can find tools such as https://regex101.com/ on the internet to help identify the regex pattern you need.

Template Architecture¶

File Structure Components¶

Templates define up to three sections for both input and response files:

Header - Optional metadata section (file information, batch details, timestamps)
Body - Data section containing the actual records to process
Footer - Optional summary section (record counts, totals, validation summaries)

File Format Support¶

FeedXChange supports two file formats: fixed and delimited.

Fixed Width Files:

Each field occupies a specific character position
Precise positioning ensures data integrity
Common in legacy systems and mainframe environments

Delimited Files:

Fields separated by delimiters (such as commas, pipes, or tabs)
More flexible and human-readable
Widely used in modern data exchanges

Important

For delimited files, the order of fields in the template must match the file exactly.

Input vs Response Files¶

Each section of an Input or Response file (that is, the Header, Footer, and Body) has a list of fields that define the layout of the file.

Input Files¶

The input file is created by the source system and contains data you want to import into ReactorCX.

Source: Created by external systems (partner systems, data sources)
Purpose: Contains data to import into ReactorCX
Examples: Member enrollments, activity data, member preference updates
Template Role: Defines how FeedXChange parses and validates the incoming data

Response Files¶

After FeedXChange downloads and processes the input file, it can generate a response file to communicate the results of the integration run back to the source system.

Source: Generated by FeedXChange after processing
Purpose: Communicates processing results back to source systems
Examples: Validation errors, processing confirmations, assigned member IDs
Template Role: Defines what information to include and how to format the response

RCX Process Types¶

Templates are associated with specific RCX processes that determine the type of data processing:

Activity - Transaction and engagement data
Enrollment - New member registration
Loyalty ID - Member identification
Member Preferences - Communication and preference settings
Member Segments - Customer segmentation assignments
Profile Update - Member information modifications

Advanced Template Features¶

Array Fields¶

Handle complex data structures with dot notation (for example, lineItems.couponCode):

Process lists of related data within a single record
Configure array lengths and field definitions
Essential for e-commerce and transaction data

Data Transforms¶

Apply data transformations during processing:

Concatenation - Combine multiple fields (FirstName + LastName)
Date formatting - Convert between date formats automatically
Value mapping - Transform codes to descriptions (1 → "Active", 0 → "Inactive")

Validation Rules¶

Ensure data quality and integrity:

Required field validation
Data type and format verification
Custom validation expressions
Length and range checking

Template Creation Approaches¶

FeedXChange offers flexible template creation methods:

Create from Scratch¶

Build templates field-by-field for unique requirements
Full control over every aspect of the template
Best for custom integrations

Copy Existing Template¶

Duplicate similar templates as starting points
Modify copies for new partners or processes
Accelerates development for similar use cases

Import Template¶

Import pre-built templates from other systems
Useful for standardized formats or migrations
Enables template sharing and reuse

Template Lifecycle¶

Development Phase¶

Design - Plan file structure and field requirements
Create - Build template using chosen creation method
Configure - Set up field definitions, transforms, and validation rules
Test - Validate with sample files to ensure proper processing

Production Phase¶

Publish - Make template available for integration use
Deploy - Associate with integrations for active processing
Monitor - Track processing results and identify issues
Maintain - Update as requirements change (requires unpublishing dependent integrations)

Template Dependencies and Relationships¶

Prerequisites:

Partner must exist before creating templates
Understanding of source system file formats
Knowledge of target RCX process requirements

Relationships:

Templates belong to specific partners
Published templates can be used by multiple integrations
Template changes affect all dependent integrations

Best Practices¶

Design Phase¶

Start with sample files - Analyze actual data before template creation
Plan for edge cases - Consider empty fields, special characters, varying lengths
Document assumptions - Record business rules and data expectations

Testing Phase¶

Use realistic test data - Create 2-3 rows of representative data
Test error conditions - Verify handling of invalid data
Validate transforms - Ensure data transformations work as expected

Production Phase¶

Version control - Use descriptive naming for template versions
Monitor processing - Review integration results often
Plan updates - Template changes require integration coordination

Template Security and Access¶

Partner isolation - Templates are scoped to specific partners
Role-based access - Create, edit, and publish permissions controlled by user roles
Publishing controls - Only published templates are available for production use
Edit restrictions - Published templates used by published integrations require unpublishing workflow