1. Correct Output Mapping Configuration
In the Execute Integration Service action's Output Mapping:
Left side (IS Service Output): Map from your service's output signature
- Example:
via (your String variable from the IS service)
Right side (AT Pipeline Variable): Create/map to an AT pipeline variable
- Example:
routingDestination or via
Configuration:
IS Service Output → AT Pipeline Variable
via → ${via}
The syntax ${variableName} makes it available in the AT action pipeline for subsequent actions.
2. Correct Run Condition Syntax in 10.15
Active Transfer 10.15 uses JavaScript expressions for Run Conditions. Here's the correct syntax:
For a Move action that should run conditionally:
In the Run Condition field of your Move action:
Or for multiple conditions:
${via} == "FTP_A" || ${via} == "FTP_PRIMARY"
Important Notes:
- Use
== for equality comparison (not =)
- String values need quotes:
"value"
- Numeric values don't need quotes:
${via} == 123
- Boolean operators:
&& (AND), || (OR), ! (NOT)
3. Using Variables in File Filter vs. Move Action
Short Answer: You cannot use pipeline variables directly in the File Filter field of a Move action. File Filters are pattern-based (wildcards like *.txt) and don't support dynamic variable substitution.
Recommended Approach: Use Run Conditions on multiple Move actions instead.
Step-by-Step Configuration
Step 1: Execute Integration Service Action
Output Mapping:
IS Output Field: via
AT Pipeline Variable: ${via}
Step 2: Create Multiple Move Actions (one per destination)
Move Action 1 - To FTP_A:
- Run Condition:
${via} == "FTP_A"
- Destination: Your FTP_A server configuration
- Source File:
${file} (from Find action)
Move Action 2 - To FTP_B:
- Run Condition:
${via} == "FTP_B"
- Destination: Your FTP_B server configuration
- Source File:
${file}
Move Action 3 - To FTP_C:
- Run Condition:
${via} == "FTP_C"
- Destination: Your FTP_C server configuration
- Source File:
${file}
Alternative: Default/Fallback Routing
If you want a default destination for unmatched values:
Move Action (Default):
- Run Condition:
${via} != "FTP_A" && ${via} != "FTP_B" && ${via} != "FTP_C"
- Destination: Your default/error FTP location
Troubleshooting Tips
-
Verify Variable in Pipeline:
- You mentioned you can see it in email body - good sign!
- Add a Log action before Move actions:
Routing to: ${via}
-
Check Variable Type:
- Ensure your IS service returns a String (not Document or other type)
- Trim whitespace in IS:
pub.string:trim before returning
-
Test Run Conditions:
- Start with simple condition:
${via} != null
- Then add specific value checks
-
Common Issues:
- Case sensitivity:
"FTP_A" ≠ "ftp_a"
- Extra spaces:
"FTP_A " ≠ "FTP_A"
- Null values: Add null check:
${via} != null && ${via} == "FTP_A"
Should You Use IS Only Instead?
Use AT when:
- You need AT's built-in FTP/SFTP management
- You want visual action-based configuration
- Multiple teams manage different parts (AT admins vs. IS developers)
- You need AT's monitoring and retry capabilities
Use IS only when:
- Complex conditional logic (nested if/else)
- Need to call multiple external systems
- Require transaction management
- AT's action-based approach becomes too cumbersome
For your use case with 2-3 destinations, AT with Run Conditions is perfectly suitable and keeps the routing logic visible in the AT interface.
Example IS Service Output Structure
Your IS service should return:
Output Signature:
via (String)
Sample IS flow logic:
1. Read file content
2. Parse/extract routing info
3. Map to 'via' output variable
4. Return (via will be in pipeline output)
------------------------------
Shashank Mitra
------------------------------