# Endpoint Proxying

BDeploy supports proxying (tunneling) to application endpoints as defined in the app-info.yaml.

The application hosting the endpoint to call can be hosted on any node within the system. As long as this node is attached to a master you can reach (directly in STANDALONE or MANAGED mode, or indirectly in CENTRAL mode), you can tunnel there using BDeploy.

You will need the following information to be able to call an Endpoint of a remote application through the BDeploy public API:

• A BDeploy slim token to be supplied for an authorization header in the form of X-BDeploy-Authorization: Bearer <TOKEN>. You can obtain this token from the Web UI for the logged in user.
• The ID of the instance group hosting the application you want to tunnel to.
• The ID of the instance hosting the application you want to tunnel to. You can see this ID for instance from the browser's URL when on the instance overview page for the instance in question.
• The ID of the application's endpoint as defined in the app-info.yaml.
• The ID of the application which hosts the endpoint identified by the endpoint ID above.

A typical proxy call using the public API would look like this, when using cURL:

curl -k -L -H "Accept: */*" \
    -H "X-BDeploy-Authorization: Bearer <X>" \ <1>
    "https://server/api/public/v1/common/proxy/myEndpoint?BDeploy_group=MyGroup&BDeploy_instance=xxxx-111-xxxx&BDeploy_application=yyyy-111-yyyy" <2> <3> <4> <5> <6>

1. <X> is a bearer token, which can be obtained from the Web UI (User drop-down menu).
2. server is the hostname (and port) of the BDeploy master. This may be either a CENTRAL, MANAGED or STANDALONE server, being in charge (directly or indirectly) of the application to tunnel to.
3. myEndpoint is the ID of the endpoint to call as defined in the app-info.yaml of the hosting application.
4. MyGroup is the ID of the instance group which hosts the application to tunnel to.
5. xxxx-111-xxxx is the ID of the instance which hosts the application to tunnel to.
6. yyyy-111-yyyy is the ID of the application which hosts an endpoint with the given endpoint ID.

There are two ways to obtain required IDs. You can use a purely manual approach and for example deduce ID's from URLs and the Web UI itself. Or you can use the public API to query BDeploy for available objects.

http://my-server/#/instances/dashboard/MyGroup/xxxx-111-xxxx

From the above URL, you can find the instance group ID (MyGroup) as well as the instance ID (xxxx-111-xxxx). When on the instance dashboard, click the server application you want to tunnel to. The process control panel for that application opens up, and you will see the application's process ID displayed.

Last thing to manually lookup is the endpoint ID. Endpoints can be accessed on the instance configuration page by clicking on the application you want to tunnel to and then clicking on [ Configure Endpoints ]

You will be able to read the endpoint ID and configured properties of the endpoint on this page. The configuration will be used by BDeploy when instructed remotely to call that endpoint. BDeploy will take care of things like authentication, security, etc. The actual caller will only require access (and permissions) on the master server they are calling into, not to the actual application. Instead, BDeploy itself is configured to be authorized to perform the call.

For automatic lookup, you can use the following BDeploy public API endpoints. Those are provided by the master server, same as the actual proxy endpoint:

# will list instance groups
curl -k -H "Accept: application/json" \
    -H "X-BDeploy-Authorization: Bearer <X>" \ <1>
    "https://server/api/public/v1/instanceGroups"

# will fetch the latest configuration of all instances in an instance group
curl -k -H "Accept: application/json" \
    -H "X-BDeploy-Authorization: Bearer <X>" \
    "https://server/api/public/v1/common/instances?BDeploy_group=MyGroup&latest=true" <2>

# will fetch all endpoints exposed by a certain instance along with the ids of the applications hosting them.
curl -k -H "Accept: application/json" \
    -H "X-BDeploy-Authorization: Bearer <X>" \
    "https://server/api/public/v1/common/endpoints?BDeploy_group=MyGroup&BDeploy_instance=xxxx-111-xxxx" <2> <3>

1. <X> in the following cURL calls is the bearer token as obtained from the Web UI.
2. MyGroup is the name of one of the instance groups as obtained by the first API. You can fetch the ID of each instance from the returned JSON.
3. xxxx-111-xxxx is the instance ID as obtained by the second API. The returned JSON will include the application ID hosting the endpoint along with the actual specific configuration of that endpoint (including its ID).

UI Endpoints can be defined to allow simple access to hosted web applications in a similar manner to client applications. This means that BDeploy will provide a link to the web application in much the same way as it provides access to client applications in its own UI, both on the (server) process status panel, as well as on the client applications page.

A sample UI endpoint definition may look something like this in the app-info.yaml:

endpoints:
  http:
    - id: "appUi"
      enabled: "{{V:port-param}}"
      path: "/"
      contextPath: "/appUi"
      port: "8080"
      secure: false
      authType: NONE
      type: UI
      proxying: true

The enabled flag controls whether the endpoint is configured and visible to the end user. The expression is evaluated against the current configuration, and the endpoint is hidden in case the enabled condition evaluates to null, empty, false or cannot be resolved at all.

Much like "normal" Endpoint Proxying, BDeploy also provides proxying for UI endpoints - when enabled using the proxying attribute on the endpoint. A UI endpoint will be reachable on any participating BDeploy server (STANDALONE only or CENTRAL and MANAGED if used). BDeploy handles all the traffic from and to the actual web application. There is no direct access to the actual application required.