NOTE: As TIBCO Cloud Integration Hybrid Agent (TIBAGENT) internally embedded Proxy Agent (TIBTUNNEL), This FAQ is also applicable for TIBCO Cloud Integration Hybrid Agent (TIBAGENT).
TIBCO Cloud Hybrid Connectivity - Proxy Agent (TIBTUNNEL) FAQ
- What are the minimum specifications for a machine to host TIBCO Cloud Hybrid Connectivity Proxy Agent?
- Operating System Requirement: TIBCO certified HCPA on Mac OS 10.x, Linux 7.5, and Windows 10.
- CPU Requirement: Minimum of 1 CPU.
- RAM Requirement: tibtunnel needs a minimum of 256 MB. [Note: tibtunnel could be memory-intensive, depending on traffic; memory requirement increases with increasing traffic.]
- Virtual Hard Disk: Minimum of 10 MB, which is the size of tibtunnel Proxy Agent.
- How to configure tibtunnel Proxy Agent?
While considering Hybrid Connectivity Proxy Agent (tibtunnel), users may have concerns such as the following: - A single tibtunnel per app, or
- multiple apps per single tibtunnel, or
- whether tibtunnel should be configured per resource (DB or Service which can be accessed by multiple apps), and so on.
The decision lies with the user (i.e. the customer) but the choice should depend on the use case. That being said, it is worth noting that tibtunnel supports multiple ConnectURL (app endpoint).
./tibtunnel connect [--profile <profileName>] -s <spec> [-s <spec> ...] <ConnectURL> E.g. AppID1 and AppID2 are configured to connect to On prem EMS Server : ./tibtunnel connect -progile <MyProfile> -s 7222:<EMS HOSTNAME>:7222 https://integration.cloud.tibcoapps.com/tunnel/<appID1> https://integration.cloud.tibcoapps.com/tunnel/<appID-2> |
- Can I run tibtunnel twice with the same profile (and hence same access key) and point to different ports?
Yes, multiple instances of tibtunel can run with the same profile (i.e. same access key).
- I need to connect to EMS and Oracle On-Premise. Could both EMS and Oracle use the same access key, or do the two require separate access keys, one per each data source?
tibtunnel supports the following format:
./tibtunnel connect [--profile <profileName>] -s <spec> [-s <spec> ...] <ConnectURL> |
This means that a single instance of tibtunnel supports multiple specs as well as multiple ConnectURL. In other words, a single tibtunnel should suffice. ./tibtunnel connect -progile <MyProfile> -s 7222:<EMS HOSTNAME>:7222 -s <Port Exposed in container>:<OracleHostName>:<OnPrem:PORT> https://integration.cloud.tibcoapps.com/tunnel/<appID1> https://integration.cloud.tibcoapps.com/tunnel/<appID-2> |
- All TIBCO Cloud applications will refer to a proxy agent and establish communication through relevant tibtunnels. Would the scenario cause bottleneck for the proxy agent server?
- The proxy agent server is running inside each container that has hybrid connection enabled; therefore, there should be no bottleneck. Hybrid connectivity traffic is viewed as normal endpoint traffic via TIBCO Cloud Router.
- How resource-intensive would maintaining tibtunnels for each TIBCO Cloud application be, and should enhancing the server hardware be considered in order to maintain high throughput?
- The tibtunnel is not resourced-intensive, and throughput depends largely the TIBCO Cloud Router load since traffic is shared with normal application endpoint traffic.
- What type of transport mechanism and encryption mechanism are used by TIBCO Cloud Proxy Agent?
- Does tibtunnel support resource configuration behind a corporate proxy like HTTP Proxy?
- An environment variable similar to the following must be set before starting tibtunnel:
export HTTP_PROXY=http://http_proxy:port/ If we have HTTPS Proxy then export HTTPS_PROXY=https://https_proxy:port/ |
- What is the advantage of Hybrid Connectivity Proxy Agent over VPN?
- How to generate an access key for Hybrid Connectivity Proxy Agent (tibtunnel)?
In order to TIBCO Cloud Proxy Agent, you must first create an access key:
- Login to TIBCO Cloud then navigate to Settings -> Advanced Settings -> TIBCO Cloud - Proxy Agent access keys.
- Click Create to create a new access key.
- Enter the Access Key ID in the text box then click Create. The Secret Access Key is generated and should be displayed.
Note: The secret access key is only displayed once at creation time. Copy the key to a secure store.
Note: Access keys could only be generated by a user with Administrator role or Organization owner. - How to use TIBCO Cloud Proxy Agent (tibtunnel) with TCI for On-Premise Connectivity?
The procedure is documented in TCI Docs at https://integration.cloud.tibco.com/docs/using/hybrid-connectivity/proxy-agent/index.html. Customers could also be referred to KB Article:000039717: How to connect to cloud-based/on-premise applications like a database from TIBCO Cloud Integration (TCI). The article has all steps required for Hybrid Connectivity.
- How to configure/run tibtunnel in High-Availability/Fault-Tolerant mode?
High Availability (HA)
TIBCO Tunnel is designed to work in a HA mode. Multiple tunnel connection can be established at the same time by starting multiple tibtunnel processes (ideally on different machines and/or physical locations) and connecting to the same TIBCO Cloud Tunnel endpoint. When a given on-premise resource is reachable via more than one tunnel, the first tunnel (in the connection order) will be used (i.e., as active tunnel); the remaining tunnels will be in a stand-by mode and ready for use if the first tunnel fails (i.e., hot stand-by tunnel).
Fault Tolerance (FT)
When a tunnel connection fails (e.g., due to temporary network outage) the tibtunnel process will attempt to reconnect every 10 seconds. If tibtunnel was started in HA mode (see above), the first available stand-by tunnel will become the active tunnel. When the initial tunnel connection is re-established, the new connection will become a new stand-by tunnel.
- What would be the impact on tibtunnel if an application configured for Hybrid Connectivity is scaled up or down?
Application Scaling
If a TIBCO Cloud application with active tunnel connections is scaled down, the tunnel connections for the deleted instances (i.e., application docker containers) will be automatically terminated. Similarly, when an application is scaled up, the tibtunnel process will automatically discover the new application instance and a new tunnel connection will be created for the new container