Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
76 changes: 70 additions & 6 deletions docs-java/environments/kyma.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -586,7 +586,7 @@ The official [documentation of the Transparent Proxy](https://help.sap.com/docs/

You can either configure connectivity to individual destinations, or for arbitrary destinations in your destination service instance or subaccount (via Destination Gateway).

<Tabs
<Tabs
groupId="dynamic-dest"
defaultValue="single"
values={[
Expand Down Expand Up @@ -659,9 +659,22 @@ Apply the YAML with `kubectl apply -n` into the namespace of your application po

### Executing Requests

In your application you can now configure a destination to execute requests:
The SAP Cloud SDK offers two distinct approaches for executing requests through the Transparent Proxy in Kyma. Choose the approach that best fits your application's architecture and requirements.

<Tabs
## Approach 1: TransparentProxyDestination Builder (Recommended)

The **TransparentProxyDestination Builder** approach provides explicit, fine-grained control over individual destination configurations. This is the recommended approach for most use cases as it offers maximum flexibility and clear configuration management.

### When to Use This Approach

- You need specific control over individual destination configurations
- You want to set custom headers or properties per destination
- You prefer explicit destination management
- You want to consume a destination with fragment or chain

### Implementation Examples

<Tabs
groupId="dynamic-dest"
defaultValue="single"
values={[
Expand All @@ -670,6 +683,10 @@ In your application you can now configure a destination to execute requests:
]}>
<TabItem value="single">

**For Concrete SAP Destinations:**

Use this when connecting to a specific, pre-configured destination with a dedicated Destination Custom Resource.

```java
TransparentProxyDestination destination = TransparentProxyDestination
.destination(<destination-custom-resource-name>.<destination-custom-resource-namespace>)
Expand All @@ -684,6 +701,10 @@ List<SalesArea> execute = new DefaultSalesAreaService().getAllSalesArea() // exa
</TabItem>
<TabItem value="gateway">

**For Gateway:**

Use this when you need to connect to arbitrary destinations dynamically using a [Gateway Destination Custom Resource](https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/dynamic-lookup-of-destinations).

```java
TransparentProxyDestination destination = TransparentProxyDestination
.gateway("my-destination", <destination-custom-resource-name>.<destination-custom-resource-namespace>)
Expand All @@ -701,11 +722,54 @@ List<SalesArea> execute = new DefaultSalesAreaService().getAllSalesArea() // exa
`<destination-custom-resource-namespace>` can be omitted if the destination custom resource is created in the same namespace as the application workload.
:::

The code above shows an example how you can then use the `destination` object to perform an OData request against the system.
## Approach 2: Transparent Proxy Loader

The **Transparent Proxy Loader** approach provides centralized proxy configuration where **all destination requests** are automatically routed through a single registered gateway without requiring explicit destination builders.

### When to Use This Approach

- You want all destinations to automatically route through a single [Dynamic Destination Custom Resource](https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/dynamic-lookup-of-destinations)
- You prefer a centralized, "set-it-and-forget-it" configuration approach
- You have many destinations that should all use the same proxy configuration
- You want to minimize code changes when migrating from traditional destination access

### Implementation Examples

**Step 1: Register the Transparent Proxy (typically during application startup):**

```java
// Register with default port 80
TransparentProxy.register("<destination-gateway-host>");

// OR register with custom port
TransparentProxy.register("http://<destination-gateway-host>", 8080);

// OR register with provider tenant ID (default port 80)
TransparentProxy.register("<destination-gateway-host>", "provider-tenant-id");

// OR register with custom port and provider tenant ID
TransparentProxy.register("http://<destination-gateway-host>", 8080, "provider-tenant-id");
```

:::note Provider Tenant ID
The provider tenant ID serves as a fallback when the current tenant cannot be accessed during destination preparation. This is particularly useful in scenarios where tenant information is not readily available, providing a default tenant for authentication and authorization purposes.

The SAP Cloud SDK automatically sets the current tenant ID during requests. The provider tenant ID is only used as a fallback when the current tenant cannot be accessed.
:::

**Step 2: Use destinations normally - they will automatically route through the registered proxy:**

```java
// All subsequent destination requests will be routed through the registered gateway
// No explicit TransparentProxyDestination creation needed
Destination destination = DestinationAccessor.getDestination("my-destination");

List<SalesArea> execute = new DefaultSalesAreaService().getAllSalesArea() // example OData request
.execute(destination);
```

:::tip Connecting to Cloud systems
The above approach is not limited to destinations of proxy type `ON_PREMISE`.
`INTERNET` destinations are equally supported.
Both approaches support destinations of any proxy type including `ON_PREMISE` and `INTERNET` destinations.
:::

### Troubleshooting
Expand Down
Loading