What it does in BusinessWorks
Raises a fault from inside a process. Where the process declares error schemas, <config><faultName>
picks one and the input mapping builds that fault’s data, so the fault is a typed document and not
just a message. Where it declares none, the activity falls back to the built-in Generate Error input
schema and carries a message, a code and a stack trace.
The fault then behaves like any other: an enclosing Catch that matches its name handles it and the process continues down the catch branch, and an unmatched fault propagates to the caller. Callers that map fault data, most often a business error code turned into a SOAP fault, are reading the document this activity built.
The Camel equivalent
<pd:activity name="Raise Stock Fault">
<pd:type>com.tibco.pe.core.GenerateErrorActivity
</pd:type>
<pd:resourceType>ae.activities.throw</pd:resourceType>
<config>
<faultName/>
</config>
<pd:inputBindings>
<ns0:ActivityInput xmlns:ns0="http://www.tibco.com
/pe/GenerateErrorActivity/InputSchema"/>
</pd:inputBindings>
</pd:activity>// the whole activity, as emitted
.throwException(<technical fault>.class,
"Raise Stock Fault")Where the semantics diverge
The payload does not travel. The rule builds an exception from a class and a message string, and the message is the activity’s name. Whatever the input mapping assembled (error code, business reason, the offending record) is not read. A caller that used to map fault data now receives an exception whose only content is a name from a Designer canvas.
One class in practice, not two. The rule picks the business class when the activity’s
<config> contains an element named businessFault, and the technical class otherwise. No
BusinessWorks Generate Error writes such an element; the configuration element is faultName. The
business branch is therefore unreachable against real process files, and an activity called “Raise
Stock Fault” comes out as a technical fault, which is exactly what the example above shows. Both
classes belong to the platform the routes are generated into rather than to the generator, so this
page names their roles and not the classes.
That choice decides where the error goes. The generated fault policy handles the two classes
differently: a business fault is logged, a technical fault is logged and sent on to
direct:errorEvent. Collapsing every fault into the technical class routes every error down the
technical path, including the ones the original design kept away from it.
faultName is lost, so catch-by-type has nothing to match on. Downstream handling that
distinguished faults by name has to be rebuilt around the message string or around a new exception
hierarchy.
If fault data matters in your estate, and if you expose SOAP or REST faults to a caller it does, plan on a fault type per declared error schema, populated from the same mapping the source used. The generated form gives you the throw site and nothing else.
What the toolchain does
An unconditional rule, so no marker is emitted. It resolves the exception class from the presence of
a businessFault configuration element, sets the message to the activity name, and emits
.throwException(<Class>.class, "<name>"). The class names are emitted short, on the assumption
that the surrounding project imports them.
Separately, and not from this rule, the generator writes a fault-policy RouteBuilder per operation
carrying three onException clauses. All three are .handled(false): they log, optionally forward
to an error route, and let the exception continue. See Catch for what that means
for error handling as a whole.