Suriin kung ang Tables builder ay tumatanggap ng kumpletong HTTP pipeline. Ang input na iyon ay pinapalitan ang hiwalay nitong httpClient na opsyon; kung ang application ay may pipeline, i-configure ang proxy-aware na transport habang binubuo ang pipeline na iyon.

Para sa direktang Netty HTTP client input, buuin ang transport at ipasa ito sa Tables:

ProxyOptions proxy = new ProxyOptions(
    ProxyOptions.Type.HTTP,
    new InetSocketAddress("proxy.example.net", 8080)
);
proxy.setCredentials(proxyUser, proxyPassword);

HttpClient transport = new NettyAsyncHttpClientBuilder()
    .proxy(proxy)
    .build();

TableClient tables = new TableClientBuilder()
    .connectionString(storageConnectionString)
    .tableName("records")
    .httpClient(transport)
    .buildClient();

Ang HttpClient dito ay com.azure.core.http.HttpClient. Ang iba pang mga uri ay nagmumula sa Azure Core HTTP/Netty, Azure Data Tables at java.net.InetSocketAddress. Ang application ang nagbibigay ng mga variable ng configuration at credential.

Pinipili ng ProxyOptions.Type.HTTP ang intermediary; ibinibigay ng setCredentials ang account nito at maaaring alisin para sa mga endpoint na walang auth. Sa configuration na iyon, ang isang entry mula sa listahan ng HTTP proxy ay maaaring magbigay ng address para sa isang pinapayagang public Tables endpoint route; huwag mag-iwan ng proxy credential sa transport. Pinipili pa rin ng storage connection string ang Tables service.

Gumagamit ito ng connection-string authentication. Ang isang identity-credential arrangement ay maaaring may hiwalay na HTTP client para sa pagkuha ng token, na ang ruta ay kailangan ding i-configure.

Kaugnay na mga artikulo