Задайце абодва маршруты падчас ініцыялізацыі, выкарыстоўваючы менавіта той аўтэнтыфікатар IAM, які быў перададзены службе:

import java.net.InetSocketAddress;
import java.net.Proxy;
import com.ibm.cloud.sdk.core.http.HttpConfigOptions;

var proxy = new Proxy(
    Proxy.Type.HTTP,
    new InetSocketAddress("proxy.example.net", 8080));

authenticator.setProxy(proxy);

var options = new HttpConfigOptions.Builder()
    .proxy(proxy)
    .build();
service.configureClient(options);

Тут authenticator і service — існуючыя аб'екты праграмы. Прымяніце налады да пачатку атрымання токена або запытаў службы, з уключанай звычайнай праверкай сертыфіката. Калі праграма можа выкарыстоўваць публічную канчатковую кропку HTTP для абодвух прызначэнняў, падыходныя адрасы ёсць у спісе проксі HTTP.

Дзве прызначэнні ахопліваюць розныя запыты. authenticator.setProxy ахоплівае шлях токена IAM; service.configureClient прымяняе проксі да транспарту службы. Настройка аднаго не стварае маршрут іншага.

Пры збоі вызначце хост, названы ў запыце, які не ўдаўся. Паспяховае атрыманне токена звузіць праблему да шляху службы; але не даказвае, што гэты шлях атрымаў свае налады проксі.

HttpConfigOptions паходзіць з IBM Java SDK Core. Адаптуючы стары прыклад ConversationService, выкарыстоўвайце пакет Core і пакаленне службы, выбраныя праграмай, а не капіруйце стары клас сеткі, спецыфічны для службы.

Падобныя артыкулы