ორივე მარშრუტი ინიციალიზაციის დროს დააყენეთ, იმ 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 პაკეტი და სერვისის ის თაობა, რომელიც აპლიკაციამ აირჩია, ნაცვლად ძველი, სერვისზე სპეციფიკური ქსელური კლასის კოპირებისა.

დაკავშირებული სტატიები