How can I route HTTP calls in-process
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.jsonihttp-deployment1.config.jsonihttp-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"requiresinProcServerIdinProcDeploymentIdoptionally points the request at another deployment in the same runtimeinProcOnly: truemeans 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.