Call Process

What it does in BusinessWorks

Call Process invokes another process by its path in the project, given in <config><processName>. The callee’s Start schema decides what the caller has to map, the input mapping builds that document, and whatever the callee’s End activity produces comes back into the caller’s data space under the calling activity’s name. Later mappings reference it as $LookupCustomer/... the same way they reference any other activity output.

By default the call runs inside the calling job: same job identifier, same job-shared variables, same transaction, same thread. Ticking Spawn changes all of that. A spawned call starts a separate job, returns immediately with no output, and shares nothing with its parent except the input document it was handed.

Faults propagate. An uncaught fault in the callee surfaces in the caller as if it had been raised at the Call Process node, which is why so many BusinessWorks processes carry no error handling of their own.

The Camel equivalent

<pd:activity name="LookupCustomer">
  <pd:type>com.tibco.pe.core.CallProcessActivity
  </pd:type>
  <pd:resourceType>ae.process.subprocess
  </pd:resourceType>
  <config>
    <processName>/services/CustomerLookup.process
    </processName>
  </config>
  <pd:inputBindings>
    <root>
      <channel>
        <xsl:value-of select="'WHOLESALE'"/>
      </channel>
      <customerId>
        <xsl:value-of
          select="$Enrich/ActivityOutput/id"/>
      </customerId>
    </root>
  </pd:inputBindings>
</pd:activity>

// wrapped for width; one line per step in the file
.setHeader("channel", constant("WHOLESALE"))
.setHeader("customerId", constant(""))
    // TODO_HUMAN
    // output reference: $Enrich/ActivityOutput/id
.to("direct:customerLookup")

Where the semantics diverge

The output never comes back. The rule emits headers and a .to(...), and nothing that reads the callee’s result. In BusinessWorks the sub-process output is addressable as $LookupCustomer/...; in the generated route it does not exist, so every downstream mapping that referenced it is translated against a value that was never set. Those mappings are exactly the ones that come out as constant("") with a TODO_HUMAN marker, so the damage is visible, but it is visible in the caller, one activity later, not at the call itself.

The input document becomes a flat header set. Bindings are walked to their leaves and each leaf is emitted as a header named after its own tag, with no parent path. Two leaves called id under different parents collide on one header. Anything the callee expected as a structured document has to be rebuilt by hand.

Spawn is not read. The rule looks at processName and nothing else. A spawned call, which in BusinessWorks returns immediately and runs on its own job, becomes an ordinary in-line .to(...) that blocks the caller until the callee finishes. Where Spawn was used to fire off logging or notification work, the migrated route now waits for it.

Targets are resolved by file name. When the path is not in the index of known routes, the endpoint is derived from the last segment of the path with the extension stripped and non-alphanumerics replaced. Two processes with the same file name in different folders resolve to the same direct: endpoint. With processName missing altogether the target is direct:TODO_resolve_callee, which compiles and has no consumer.

Decide the callee’s return contract before you run anything: either the sub-route sets the body and you rewrite the caller to read the body, or you give it an explicit output header and rewrite the mappings to use it. There is no configuration that recovers the original data space.

What the toolchain does

An unconditional rule, so no marker appears against the Call Process itself. It emits one setHeader per input-binding leaf, then .to("direct:<target>"). In YAML output the original process path is kept as a step description; in Java DSL the description is dropped, so the only record of what was called is the endpoint name.

Two site-specific unwrap rules can be configured on top, resolving named helper sub-processes (the kind of generic dispatcher most estates grow) through to their real target instead of calling them directly. When such a helper cannot be resolved the generator emits a TODO_HUMAN warning and falls back to the normal path.