IFS Event Architecture: ECA Rules, Event Actions, and Event-Driven Integration Guide

TL;DR

• Bottom line: IFS Cloud uses an ECA (Event-Condition-Action) rule engine embedded in the database layer. Events fire on entity changes (insert/update/delete), conditions filter which changes matter, and actions execute responses — from emails and REST calls to workflow triggers and SQL execution. This is IFS's primary mechanism for outbound event-driven integration. [src1, src3]
• Key limit: Custom events fire via database triggers — enabling many custom events on high-transaction tables directly impacts database write performance. System-defined events are optimized by IFS; custom events are not. [src1, src3]
• Watch out for: Execute Online SQL event actions run within the triggering transaction. If the SQL fails, the entire business transaction rolls back — not just the event action. [src1, src2]
• Best for: Outbound notifications, webhook-style REST call-outs to external systems, triggering IFS Workflows on business entity changes, and sending conditional email alerts — all without writing custom server-side code. [src1, src2]
• Authentication: IFS Cloud APIs use OAuth 2.0 (via IFS IAM) with OpenID Connect. Basic auth is available but explicitly not recommended for production. Projection-level permissions control access to specific OData endpoints. [src6]

System Profile

IFS Cloud is an enterprise ERP platform focused on asset-intensive industries (aerospace, defense, energy, manufacturing, construction). Its event architecture is built into the Oracle database layer, implementing the ECA (Event-Condition-Action) pattern directly in PL/SQL business logic. The Event Registry manages all event definitions, conditions, and action mappings. Events can trigger seven different action types including REST calls for webhook-style outbound integrations, Workflow starts via the embedded Camunda engine, and Streams notifications for in-app messaging. This card covers the event framework across all IFS Cloud editions (24R2 and 25R1). [src1, src3, src7]

API Surfaces & Capabilities

IFS Cloud provides multiple integration surfaces. The Event Framework is the primary mechanism for outbound, reactive integrations. [src1, src3, src6]

Rate Limits & Quotas

Per-Request Limits

IFS Cloud does not publish explicit per-request rate limits for the event framework. Events fire synchronously within database transactions, so throughput is bounded by database capacity. [src1, src3]

Rolling / Daily Limits

Authentication

IFS Cloud uses OAuth 2.0 via the IFS Identity and Access Manager (IFS IAM) for API access. The event framework itself does not require separate authentication. Outbound REST Call event actions can include authentication headers. [src6]

Authentication Gotchas

• No user impersonation in OData — the authenticated user's permissions apply to all operations within the session. [src6]
• Projection-level authorization — integration users must be granted access to each specific projection. [src6]
• REST Call event actions do not auto-refresh tokens — expired static Bearer Tokens cause silent failures. Use OAuth 2.0 in Workflow delegates instead. [src5]
• IFS IAM is the single authentication gateway — if IAM is unavailable, both inbound and outbound authenticated calls fail. [src6]

Constraints

• Execute Online SQL runs within triggering transaction — failure rolls back the entire business operation. Users see a generic error with no indication the event action caused it. [src1, src2]
• Custom events use database triggers — on high-volume tables, this adds overhead to every insert/update/delete. System-defined events are embedded in PL/SQL and are more performant. [src1, src3]
• REST Call event actions are fire-and-forget — no retry, no dead letter queue, no delivery confirmation. If the target is down, the event is lost. [src2, src5]
• Streams notifications are IFS-internal only — they cannot be consumed by external applications or message brokers. [src1]
• Workflow REST Call delegate has limited capabilities — no HMAC, API keys in custom headers, mTLS, structured JSON/XML parsing, or built-in logging. [src5]
• Application Message routing requires IFS Connect configuration — specialized IFS administration knowledge needed for XML/XSLT connector setup. [src1]

Integration Pattern Decision Tree

START -- User needs event-driven integration with IFS Cloud
|-- What's the event source?
|   |-- IFS Cloud entity change (insert/update/delete)
|   |   |-- System-defined event exists?
|   |   |   |-- YES --> Use system-defined event (better performance) [src1]
|   |   |   |-- NO --> Create custom event on entity's base table [src1, src3]
|   |   |-- What action do you need?
|   |       |-- Notify external system (webhook)? --> REST Call event action [src2]
|   |       |-- Complex multi-step process? --> Start Workflow event action [src4, src7]
|   |       |-- Send email? --> E-Mail event action [src1]
|   |       |-- Execute database logic? --> Execute Online SQL (CAUTION) [src1]
|   |       |-- Notify IFS users? --> Streams Message [src1]
|   |       |-- Route to middleware? --> Application Message [src1]
|   |-- External system pushes data TO IFS Cloud?
|       |-- YES --> OData REST API (POST/PUT via projections) [src6]
|       |-- Need transformation? --> IFS Connect inbound connector [src1]
|-- Timing requirement?
|   |-- Real-time (<1s) --> REST Call event action [src2]
|   |-- Near real-time --> Workflow orchestrates async REST calls [src4, src5]
|   |-- Batch/scheduled --> OData API polling with date filter [src6]
|-- Error tolerance?
    |-- Zero-loss --> Workflow with retry + IFS Connect [src4, src5]
    |-- Best-effort --> REST Call event action (fire-and-forget) [src2]

Quick Reference

Event Action Types

Event Parameter Substitution Fields

Step-by-Step Integration Guide

1. Identify or create the event

Navigate to IFS Solution Manager > Events. Check for existing system-defined events. If none exists, create a custom event by selecting the Logical Unit, trigger type, and timing. [src1, src3]

Steps in IFS Cloud:
1. Navigate to Solution Manager > Events
2. Search for target entity (Logical Unit name)
3. If system-defined event exists: click to view (read-only except subscriptions)
4. If no system event, create Custom Event:
   - Click "+" to add new event
   - Select Logical Unit (e.g., CustomerOrderLine)
   - Set trigger: "New" / "Modify" / "Remove"
   - Set timing: "After" (post-commit, safer) or "Before" (pre-commit, can block)
   - Select attributes to expose as NEW: and OLD: parameters
   - Enable the event

Verify: Event appears in list with status "Enabled". For custom events, verify the database trigger was created.

2. Define conditions for the event action

Add conditions that filter when the action should execute. [src1]

Condition configuration:
1. Open event action configuration
2. Add conditions using parameter substitution:
   Example: NEW:ORDER_STATUS = 'Released' AND OLD:ORDER_STATUS != 'Released'
3. Multiple conditions are AND-ed by default
4. Leave conditions empty to fire on every event occurrence

Verify: Test with matching and non-matching record modifications. Only matching records trigger the action.

3. Configure a REST Call event action (webhook)

Create a REST Call action to notify external systems when the event fires. [src2]

REST Call event action setup:
1. In Event Actions, click "+" to add new action
2. Set Action Type: "REST Call"
3. Configure:
   - URL: https://external-system.example.com/webhook/ifs-event
   - Method: POST
   - Headers: Content-Type: application/json
   - Body:
     {
       "event": "order_status_change",
       "order_no": "NEW:ORDER_NO",
       "old_status": "OLD:ORDER_STATUS",
       "new_status": "NEW:ORDER_STATUS",
       "changed_by": "#USER_IDENTITY",
       "timestamp": "&EVENT_DATETIME"
     }
4. Authentication: Bearer Token (if required)
5. Enable the event action

Verify: Change a matching record. Check external system's webhook endpoint logs for the incoming POST request.

4. Configure a Workflow event action

For complex multi-step integrations, trigger a Camunda workflow instead of a direct REST call. [src4, src7]

Workflow event action setup:
1. In Event Actions, set Action Type: "Workflow"
2. Reference the deployed Workflow process definition key
3. Map event parameters to workflow input variables
4. Enable the event action

The workflow handles:
- Multiple outbound REST calls with retry logic
- Human approval tasks if needed
- Error handling and compensation

Verify: Trigger the event. Check IFS Workflow Monitor for a new workflow instance.

5. Start a workflow via REST API (external trigger)

External systems can invoke IFS Workflows directly via the Camunda REST API. [src4]

# Get OAuth token from IFS IAM
TOKEN=$(curl -s -X POST \
  "https://yourifs.cloud/auth/realms/ifs/protocol/openid-connect/token" \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['access_token'])")

# Start a workflow instance
curl -X POST \
  "https://yourifs.cloud/main/ifsapplications/projection/engine-rest/process-definition/key/MyWorkflow/start" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "withVariablesInReturn": true,
    "variables": {
      "orderNumber": {"value": "CO-12345", "type": "String"},
      "integrationTarget": {"value": "external-erp", "type": "String"}
    }
  }'

Verify: Query workflow history to confirm instance completed successfully.

6. Implement outbound REST calls from a Workflow

Use the IFS REST Call delegate within a Camunda workflow service task. [src5]

<!-- Camunda service task for REST Call delegate -->
<serviceTask id="callExternalApi" name="Call External System"
  camunda:delegateExpression="${ifsHttpConnectionDelegate}">
  <extensionElements>
    <camunda:inputOutput>
      <camunda:inputParameter name="ifsBpaHttpConnectionMethod">POST</camunda:inputParameter>
      <camunda:inputParameter name="ifsBpaHttpConnectionUrl">
        https://external-system.example.com/api/orders
      </camunda:inputParameter>
      <camunda:inputParameter name="ifsBpaHttpConnectionHeaders">
        {"Content-Type": "application/json"}
      </camunda:inputParameter>
      <camunda:inputParameter name="ifsBpaHttpConnectionBody">
        {"order_no": "${orderNumber}", "status": "${newStatus}"}
      </camunda:inputParameter>
      <camunda:inputParameter name="ifsBpaHttpConnectionOutputs">
        {"externalId": "$.id", "confirmationCode": "$.confirmation"}
      </camunda:inputParameter>
      <camunda:inputParameter name="ifsBpaRestResponseCheck">true</camunda:inputParameter>
    </camunda:inputOutput>
  </extensionElements>
</serviceTask>

Verify: After workflow completes, check that output variables are populated in workflow history.

Code Examples

Python: Receive IFS webhook events

# Input:  Incoming HTTP POST from IFS REST Call event action
# Output: Processed event data, logged and acknowledged

# pip install flask==3.x
from flask import Flask, request, jsonify
import logging, json

app = Flask(__name__)
logging.basicConfig(level=logging.INFO)

@app.route("/webhook/ifs-event", methods=["POST"])
def handle_ifs_event():
    payload = request.get_json(force=True)
    event_type = payload.get("event", "unknown")
    logging.info(f"IFS event: {event_type} | {json.dumps(payload)}")

    if event_type == "order_status_change":
        order_no = payload.get("order_no")
        new_status = payload.get("new_status")
        # Add your business logic here

    return jsonify({"status": "received"}), 200

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

JavaScript/Node.js: OData polling fallback

// Input:  IFS Cloud instance URL, OAuth credentials
// Output: Changed records since last poll timestamp

// npm install [email protected]
const axios = require("axios");

async function getIfsToken(ifsUrl, clientId, clientSecret) {
  const resp = await axios.post(
    `${ifsUrl}/auth/realms/ifs/protocol/openid-connect/token`,
    new URLSearchParams({
      grant_type: "client_credentials",
      client_id: clientId,
      client_secret: clientSecret,
    }),
    { headers: { "Content-Type": "application/x-www-form-urlencoded" } }
  );
  return resp.data.access_token;
}

async function pollChangedOrders(ifsUrl, token, sinceTimestamp) {
  const url = `${ifsUrl}/main/ifsapplications/projection/v1/CustomerOrderHandling.svc/CustomerOrderSet`;
  const resp = await axios.get(url, {
    headers: { Authorization: `Bearer ${token}`, Accept: "application/json" },
    params: { $filter: `Objversion gt '${sinceTimestamp}'`, $top: 100 },
  });
  return resp.data.value || [];
}

cURL: Test IFS Cloud connectivity

# Step 1: Get OAuth token
TOKEN=$(curl -s -X POST \
  "https://yourifs.cloud/auth/realms/ifs/protocol/openid-connect/token" \
  -d "grant_type=client_credentials&client_id=ID&client_secret=SECRET" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['access_token'])")

# Step 2: Query OData projection
curl -s "https://yourifs.cloud/main/ifsapplications/projection/v1/CustomerOrderHandling.svc/CustomerOrderSet?\$top=3" \
  -H "Authorization: Bearer $TOKEN" -H "Accept: application/json"

# Step 3: List workflow process definitions
curl -s "https://yourifs.cloud/main/ifsapplications/projection/engine-rest/process-definition" \
  -H "Authorization: Bearer $TOKEN" | python3 -m json.tool

Data Mapping

Event Parameter Mapping Reference

Data Type Gotchas

• Event datetime uses the IFS application server's time zone, not UTC. Convert explicitly in the receiving system. [src3]
• NULL values in substitution fields resolve to empty strings, not JSON null. Handle empty strings as potential NULLs. [src1, src3]
• ROWKEY is essential for deep linking — always include it in outbound event payloads for traceability. [src3]
• Numeric precision varies by entity and IFS configuration. Do not assume fixed decimal places. [src1]

Error Handling & Failure Points

Common Error Scenarios

Failure Points in Production

• Execute Online SQL cascading rollback: SQL that violates a constraint rolls back the entire triggering transaction. Users see "Error executing request" with no indication the event action caused it. Fix: Wrap all SQL in BEGIN...EXCEPTION...END blocks. Log errors to a custom error table instead of raising exceptions. [src1]
• REST Call silent failure during target downtime: Events that fire while the external endpoint is down are permanently lost. No retry, no dead letter queue. Fix: Use polling with OData date filters as reconciliation fallback. For critical events, use Workflow with retry logic. [src2]
• Custom event trigger accumulation: Obsolete custom events create unnecessary database triggers on every DML. Fix: Audit custom events quarterly. Disable events no longer needed. Prefer system-defined events. [src1, src3]
• Workflow variable type mismatch: Numeric event parameter passed to String workflow variable causes silent failure. Fix: Explicitly declare variable types in both event action mapping and workflow definition. [src4]

Anti-Patterns

Wrong: Using Execute Online SQL for external integration

-- BAD: runs in triggering transaction; HTTP call failure rolls back user's order
BEGIN
  send_http_request('https://external.com/api', :NEW:ORDER_NO);
  INSERT INTO external_db_link.orders VALUES (:NEW:ORDER_NO, :NEW:STATUS);
END;

Correct: Use REST Call event action or Workflow

-- GOOD: REST Call action fires within transaction but does not block on failure.
-- For guaranteed delivery, use Workflow:
Event Action Type: REST Call (or Workflow for retry)
URL: https://external.com/api/webhook
Method: POST
Body: {"order_no": "NEW:ORDER_NO", "status": "NEW:ORDER_STATUS"}

Wrong: Creating redundant custom events

-- BAD: creates a redundant database trigger alongside existing system event
Custom Event: CustomerOrder_Modify_After
(System-defined event already exists for CustomerOrder status changes)

Correct: Register actions on existing system-defined events

-- GOOD: attach action to existing system-defined event, no extra trigger overhead
Event: CustomerOrder.StatusChanged (system-defined)
Action Type: REST Call
Condition: NEW:ORDER_STATUS = 'Released'

Wrong: Relying solely on REST Call for mission-critical sync

-- BAD: no retry, no delivery confirmation, no dead letter queue
Event: InventoryTransaction.New
Action: REST Call to WMS
(If WMS is down 10 minutes, all inventory events are permanently lost)

Correct: Workflow with retry + polling fallback

-- GOOD: Workflow handles retry; polling catches gaps
Event: InventoryTransaction.New
Action: Start Workflow "InventorySyncWorkflow"
  - Service Task: REST Call to WMS (3 retries, exponential backoff)
  - Error Handler: Log to error table, send alert email

PLUS: Scheduled OData polling job every 15 minutes as reconciliation

Common Pitfalls

• Assuming events fire after transaction commit: "After" events fire after business logic but still within the database transaction. External side effects (REST call sent) cannot be undone if a later operation fails. Fix: Use Application Message (async, fires after commit) or design receiving system to handle orphan events. [src1]
• Overloading events with complex Execute Online SQL: Increases transaction lock time and makes debugging nearly impossible. Fix: Keep Execute Online SQL to simple validations. Move complex logic to Workflows. [src1]
• Not testing with production data volumes: Event actions that work in test may cause performance issues on high-volume tables. Fix: Load-test custom events with production-representative data volumes. [src1, src3]
• Hardcoding URLs in REST Call event actions: Migration between environments causes silent delivery failures. Fix: Use a configuration table or IFS System Parameter for target URLs. [src2]
• Ignoring Before vs After event timing: "Before" events can block transactions; "After" cannot. Wrong timing causes unwanted blocking or missing data. Fix: Use "After" for notifications and integrations. Use "Before" only for validations. [src1]
• Not monitoring Workflow engine health: If Camunda is overloaded, events fire but no workflow instances are created. Fix: Monitor Camunda REST API (/engine-rest/process-instance). Alert on creation latency. [src4]

Diagnostic Commands

# Test IFS Cloud OAuth authentication
curl -s -X POST "https://yourifs.cloud/auth/realms/ifs/protocol/openid-connect/token" \
  -d "grant_type=client_credentials&client_id=CLIENT_ID&client_secret=SECRET" \
  | python3 -c "import sys,json;d=json.load(sys.stdin);print('Auth OK' if 'access_token' in d else f'Error: {d}')"

# Verify OData projection accessibility
curl -s "https://yourifs.cloud/main/ifsapplications/projection/v1/CustomerOrderHandling.svc/$metadata" \
  -H "Authorization: Bearer $TOKEN" -H "Accept: application/xml" | head -20

# List deployed workflow process definitions
curl -s "https://yourifs.cloud/main/ifsapplications/projection/engine-rest/process-definition" \
  -H "Authorization: Bearer $TOKEN" | python3 -c "import sys,json;[print(p['key'],p['name']) for p in json.load(sys.stdin)]"

# Check workflow instance history (last 10)
curl -s "https://yourifs.cloud/main/ifsapplications/projection/engine-rest/history/process-instance?sortBy=startTime&sortOrder=desc&maxResults=10" \
  -H "Authorization: Bearer $TOKEN" | python3 -m json.tool

# Monitor active workflow instances
curl -s "https://yourifs.cloud/main/ifsapplications/projection/engine-rest/process-instance?active=true" \
  -H "Authorization: Bearer $TOKEN" | python3 -c "import sys,json;d=json.load(sys.stdin);print(f'{len(d)} active instances')"

Version History & Compatibility

When to Use / When Not to Use

Important Caveats

• The IFS Event Framework is tightly coupled to the Oracle database layer. Custom events create database triggers that add overhead to every DML operation on the affected table, regardless of whether conditions match. Performance testing with production data volumes is essential. [src1, src3]
• REST Call event actions are fire-and-forget with no built-in retry or delivery tracking. For mission-critical integrations, use Workflow event actions with explicit retry logic, or implement an OData polling reconciliation mechanism. [src2, src5]
• The IFS REST Call Workflow delegate has known limitations: no advanced authentication methods, limited response parsing, and no built-in logging. Complex outbound integrations may require a dedicated middleware layer. [src5]
• Event action configurations are environment-specific. When promoting from dev to production, all configurations (URLs, credentials, conditions) must be manually verified. There is no automated environment-aware mechanism. [src1, src2]
• IFS Cloud's authentication model changed significantly from IFS Applications 10. Legacy integrations using direct database connections or basic auth must be migrated to OAuth 2.0 via IFS IAM. [src6]