Skip to main content

How can I route HTTP calls in-process

· 2 min read
Jeremy Scott
Co-founder

Opscotch 3.1.1 expands bootstrap networking so an external-host call can be routed internally instead of going over the network.

This is done by combining:

  • allowExternalHostAccess[].transport = "inProc"
  • allowHttpServerAccess[].inProcOnly = true

Use in-process routing when the calling workflow already works in HTTP terms and you want to preserve that contract, but the target is another deployment in the same runtime.

The workflow still uses context.setUrl(...).

The receiver still uses an http trigger.

The difference is that the transport stays inside the agent process.

Example

The cross-deployment example app in opscotch-community shows the pattern:

  • cross-deployment-internal-http.bootstrap.json
  • ihttp-deployment1.config.json
  • ihttp-deployment2.config.json

Caller bootstrap:

{
"allowExternalHostAccess": [
{
"id": "otherhost",
"transport": "inProc",
"inProcServerId": "inProcOnly",
"inProcDeploymentId": "deployment2"
}
]
}

Receiver bootstrap:

{
"allowHttpServerAccess": [
{
"id": "inProcOnly",
"inProcOnly": true
}
]
}

Caller workflow:

{
"urlGenerator": {
"script": "context.setUrl(\"otherhost\", \"/pong\")"
}
}

Receiver workflow:

{
"trigger": {
"http": {
"server": "inProcOnly",
"path": "/pong",
"method": "GET"
}
}
}

Important Details

  • transport: "inProc" requires inProcServerId
  • inProcDeploymentId optionally points the request at another deployment in the same runtime
  • inProcOnly: true means the server does not bind a host port
  • this preserves HTTP semantics, but removes host-network overhead

When to Use It

Use in-process routing when:

  • you want bootstrap-only rerouting
  • you want to preserve an existing HTTP-shaped workflow
  • you want internal-only reachability without opening a port

If you want direct step-to-step calls rather than HTTP-style routing, use the cross-deployment allowDeploymentAccess path instead.