QSYS2.HTTP_GET neem die bestemmings-URL en daarna n JSON-opsiedokument. Die proxy-adres gebruik host,port, nie n proxy-URL nie. Vir n ongemagtigde gewone HTTP-proxy kan die opsies so lyk:

VALUES QSYS2.HTTP_GET(
  'https://api.example.net/status',
  '{"proxy":"proxy.example.net,8080",
    "proxySsl":"false",
    "headers":{"Accept":"application/json"}}'
);

proxySsl beskryf die verbinding na die proxy. IBM dokumenteer die verstek as true, so skakel dit uit wanneer die luisteraar gewone HTTP verwag. Die bestemming bly HTTPS. Vir n toegelate toets kan n eindpunt uit die HTTP-proxylys die gasheer en poort as kommageskeide waarde invul.

Magtiging het n aparte grens. proxyAuth word as userid,password gedokumenteer en is net toegelaat wanneer proxySsl true is. basicAuth gee geloofsbriewe vir die bestemming. n Oorsprong-opskrif kan nie proxy-magtiging vervang nie.

Om n gebruikersnaam en wagwoord te gee kies nie NTLM nie. Die gepubliseerde SQL-opsies het geen NTLM-kieser nie. As die proxy NTLM vereis, bepaal of dit vir die geinstalleerde vrystelling ondersteun word.

Onderskei ook die twee IBM SQL HTTP-families. QSYS2 gebruik ILE; die ouer SYSTOOLS gebruik Java. n Java Authenticator vir SYSTOOLS is nie QSYS2-konfigurasie nie.

Pas opsiebeskikbaarheid, insluitend die objekvorm van headers, by die dokumentasie vir die geinstalleerde vrystelling en PTF-vlak. Kies n ander transport as die proxy se magtiging dit vereis.

Verwante artikels