What the JavaScript action is
The JavaScript action in OIC lets you write and execute ECMAScript 5-compatible JavaScript directly inside an orchestration flow. It has access to the integration’s variables and can read and write them, making it a flexible escape hatch for logic that XSLT or native OIC actions can’t handle cleanly.
Good use cases
Complex string manipulation — JavaScript’s string functions are more readable than XSLT for multi-step transformations:
var raw = input.phone.replace(/[^0-9]/g, '');
if (raw.length === 10) return '+91' + raw;
return raw;
Array operations — filtering, reducing, or restructuring JSON arrays:
var active = input.employees.filter(function(e) {
return e.status === 'ACTIVE' && e.department === 'IT';
});
return active.map(function(e) { return e.employeeId; });
Dynamic key lookup — when you need to compute a field name at runtime:
var fieldName = 'amount_' + input.currency.toLowerCase();
return input[fieldName] || 0;
What to avoid
Don’t use JavaScript actions for:
- Logic that native XSLT mapper can handle (adds unnecessary complexity)
- External HTTP calls (use a REST invoke action instead)
- Anything requiring ES6+ syntax (OIC uses ECMAScript 5)
- Long, multi-purpose scripts that mix different concerns
ECMAScript 5 limitations to know
No let or const — use var. No arrow functions — use function(). No template literals — use string concatenation. No Promise or async/await — JavaScript actions are synchronous.
Variable passing
Pass variables to the JavaScript action via its input mapping, and read results from its output. Don’t try to directly reference OIC variables inside the script using their path notation — it won’t work. Always go through the input/output mapping.
Debugging JavaScript actions
Add console.log() calls — the output appears in OIC’s activity stream for the integration instance, making it easy to inspect intermediate values during development. Remove them before production deployment.
Keep scripts small and focused
A JavaScript action should do one thing. If you find yourself writing a 50-line script, it’s a signal to either: move the logic to a PL/SQL stored procedure and call it via the DB adapter, or split the action chain into smaller, testable pieces.