ESBExit

HTTP Request

Sends an outbound HTTP call. The generator wires the route but delegates URL construction to a bean it auto-stubs as a no-op, so the route compiles before anyone has implemented it.

Translated com.tibco.plugin.http.client.HttpRequestActivity

What it does in BusinessWorks

Sends an HTTP request to a target built from the activity’s configuration: host, port, path and whether the connection is TLS, each of which can be a literal or mapped from the data space. The input mapping fills the request body and any headers, and the activity’s output carries the response (status, headers and body) addressable downstream the same way any other activity output is.

Timeouts, retries and connection reuse are engine-level HTTP client settings, not part of the activity itself, which is why they rarely show up in the process file and easily get lost in a migration that only reads the activity.

The Camel equivalent

BusinessWorks 5.process
<pd:activity name="Call Pricing Service">
  <pd:type>com.tibco.plugin.http.client
    .HttpRequestActivity
  </pd:type>
  <config>
    <httpMethod>POST</httpMethod>
  </config>
  <pd:inputBindings>
    <Host>
      <xsl:value-of
        select="'api.internal.example.net'"/>
    </Host>
    <Port>
      <xsl:value-of select="'443'"/>
    </Port>
    <RequestURI>
      <xsl:value-of select="'/v1/orders'"/>
    </RequestURI>
    <EnableSSL>
      <xsl:value-of select="'true'"/>
    </EnableSSL>
  </pd:inputBindings>
</pd:activity>
Apache CamelJava DSL, generated
// the whole activity, as emitted
.setHeader("CamelHttpMethod", constant("POST"))
.setHeader("tibco_host", simple("..."))
.setHeader("tibco_port", simple("..."))
.setHeader("tibco_requesturi", simple("..."))
.setHeader("tibco_enablessl", simple("..."))
.bean("sendHTTPRequestHttpRequestBuilder",
    "build")
.toD("${header.targetUrl}"
    + "?throwExceptionOnFailure=false")
.bean("sendHTTPRequestHttpResponseHandler",
    "handle")

Where the semantics diverge

Building the URL is not this rule’s job, and nothing fills it in by default. The four configuration fields become four headers with a tibco_ prefix, and the actual request target, ${header.targetUrl}, is left to a bean the rule names but does not write: <name>HttpRequestBuilder. Until that bean is implemented, the generator’s own fallback registers it as a stub, a pass-through that returns the body unchanged and sets no header at all. The route compiles and starts; targetUrl is simply never set, so the request has nowhere to go.

That fallback is deliberate, and worth understanding on its own terms. Every bean name the generator references but does not generate a real implementation for gets a matching stub in a shared CommonStubBeans configuration, guarded by @ConditionalOnMissingBean so a real @Component under the same name silently takes over once written. It is what keeps a whole module compiling before every activity in it has been ported by hand: useful during a migration in progress, and easy to mistake for a working integration if the stub is never replaced.

The response handler has the same shape and the same gap. <name>HttpResponseHandler is expected to turn the raw HTTP response into whatever the process mapped downstream from this activity’s output; unimplemented, its stub does the same pass-through.

Retries, timeouts and connection reuse are not read. Whatever the engine’s HTTP resource configured is not part of this activity’s own <config>, is not looked at by the rule, and has no equivalent in the generated route: the .toD(...) call carries only throwExceptionOnFailure=false.

Treat HttpRequestBuilder and HttpResponseHandler as the two beans every migrated HTTP call needs written by hand: the first setting targetUrl and any headers the target expects, the second mapping the response body and status the way the original activity’s output was consumed.

What the toolchain does

An unconditional rule, so no marker is attached to the activity itself. It sets CamelHttpMethod from the configured method, sets a tibco_<field> header for each of Host, Port, RequestURI and EnableSSL that has an input binding, calls a builder bean, sends with .toD("${header.targetUrl}?throwExceptionOnFailure=false"), then calls a handler bean. Both beans are named after the activity and are auto-stubbed, as described above, until a real implementation with the same Spring bean name replaces the stub.

Related activities