Csatlakozás külső HTTP-szolgáltatásokhoz

A HTTP-kapcsolat egy Unity Catalog biztonságos objektum, amely egy külső HTTP-szolgáltatás végpont- és hitelesítő adatait tárolja. HTTP kapcsolatot használj hitelesítési kérések küldésére külső REST API-kba az Azure Databricks-ből anélkül, hogy beágyaznád a kódodba a hitelesítő adatokat. Az ügynökök külső Model Context Protocol (MCP) szerverekhez való csatlakoztatásához használjuk az MCP szolgáltatásokat, amelyek integrálódnak a Unity Catalog HTTP kapcsolataival. Sémaszintű HTTP kapcsolatok általában elérhetők; a metastore szintű kapcsolatok Public Preview módban találhatók.

Régiónkénti elérhetőség

A Unity Catalog HTTP-kapcsolatai csak olyan régiókban érhetők el, ahol a modellkiszolgáló támogatott. Lásd: A modell kiszolgálói funkcióinak rendelkezésre állása.

Mielőtt hozzákezdene

Munkaterületre vonatkozó követelmények:

• A Unity Cataloghoz engedélyezett munkaterület. A 2023. november 9. után létrehozott munkaterületek automatikusan engedélyezve vannak a Unity Katalógusban, beleértve az automatikus metaadattár-kiépítést is. Nem kell manuálisan létrehoznia egy metaadattárat, hacsak a munkaterület nem előzi meg az automatikus engedélyezést, és nem lett aktiválva a Unity Catalog számára. Tekintse meg a Unity Catalog használatának első lépéseit.

Számítási követelmények:

• Azure Databricks számításnak a Databricks Runtime 15.4 LTS vagy újabb verzióját kell használnia, és Standard vagy Dedicated hozzáférési módot kell használnia.
• Az SQL-raktáraknak pro- vagy kiszolgáló nélkülinek kell lenniük, és a 2023.40-et vagy újabb verziót kell használniuk.

Szükséges engedélyek:

• Kapcsolat létrehozásához metaadattár-rendszergazdának vagy CREATE CONNECTION jogosultsággal rendelkező felhasználónak kell lennie a munkaterülethez csatolt Unity Catalog metaadattárban. A Unity Cataloghoz automatikusan engedélyezett munkaterületeken alapértelmezés szerint a munkaterület rendszergazdái rendelkeznek a CREATE CONNECTION jogosultsággal.

Az alábbi tevékenységalapú szakaszokban további engedélykövetelmények vannak megadva.

• A külső szolgáltatás hitelesítésének beállítása az alábbi módszerek egyikével:
  • Tulajdonosi jogkivonat: Tulajdonosi jogkivonat beszerzése egyszerű jogkivonat-alapú hitelesítéshez.
  • Dinamikus ügyfélregisztráció (DCR):OAuth-hitelesítő adatok automatikus felderítése és regisztrálása az RFC 7591 protokoll használatával. Minden felhasználó egyenként hitelesít.
  • OAuth 2.0 Gépről gépre: Alkalmazás létrehozása és konfigurálása a gépről gépre történő hitelesítés engedélyezéséhez.
  • OAuth 2.0 Megosztott felhasználó–gép: Hitelesítés felhasználói beavatkozással a szolgáltatásidentitás és a gép közötti hozzáférés megosztásához.
  • OAuth 2.0 Felhasználó-gép interakció felhasználónként: Hitelesítse felhasználónkénti interakcióval a felhasználói identitás és a gép közötti hozzáféréshez.

Hitelesítési módszerek külső szolgáltatásokhoz

Tulajdonosi jogkivonat

A tulajdonosi jogkivonat egy egyszerű jogkivonat-alapú hitelesítési mechanizmus, amelyben egy jogkivonatot adnak ki egy ügyfélnek, és az erőforrások eléréséhez használják további hitelesítő adatok megkövetelése nélkül. A token szerepel a kérelem fejlécében, és mindaddig hozzáférést biztosít, amíg érvényes.

OAuth Gép-gép közötti kommunikáció

Az OAuth Machine-to-Machine (M2M) hitelesítést akkor használják, ha két rendszer vagy alkalmazás közvetlen felhasználói beavatkozás nélkül kommunikál. A jogkivonatok egy regisztrált számítógép-ügyfél számára vannak kibocsátva, amely a saját hitelesítő adatait használja a hitelesítéshez. Ez ideális kiszolgálóról kiszolgálóra irányuló kommunikációhoz, mikroszolgáltatásokhoz és automatizálási feladatokhoz, ahol nincs szükség felhasználói környezetre. A Databricks az OAuth Machine-to-Machine használatát javasolja, amikor az elérhető az OAuth User-to-Machine Shared megoldás helyett.

Megosztott OAuth felhasználó–gép

Az OAuth felhasználó–gép megosztott hitelesítés lehetővé teszi, hogy egyetlen felhasználói identitás több ügyfél vagy felhasználó azonos hitelesítő adatait hitelesítse és ossza meg. Minden felhasználó ugyanazt a hozzáférési jogkivonatot használja. Ez a megközelítés olyan megosztott eszközökhöz vagy környezetekhez használható, ahol elegendő a konzisztens felhasználói identitás, de csökkenti az egyéni elszámoltathatóságot és nyomon követést. Azokban az esetekben, amikor identitás-bejelentkezésre van szükség, válassza a Felhasználó-gép megosztott lehetőséget. A Databricks az OAuth Machine-to-Machine használatát javasolja, amikor az elérhető az OAuth User-to-Machine Shared megoldás helyett.

Dinamikus ügyfélregisztráció (DCR)

A dinamikus ügyfélregisztráció (DCR) az RFC 7591 protokollal automatikusan felderíti az OAuth-végpontokat, és regisztrál egy ügyfelet a külső szolgáltatásban. Csak a gazdagép URL-címét adja meg, a többit pedig a Databricks kezeli – felderíti az engedélyezési kiszolgálót, regisztrálja az OAuth hitelesítő adatait, és kezeli a felhasználónkénti hozzájárulási folyamatokat. Minden felhasználónak engedélyeznie kell az első használatot, ami lehetővé teszi az egyéni hozzáférés-vezérlést és az elszámoltathatóságot. A külső szolgáltatásnak támogatnia kell az OAuth 2.0 DCR-t, és közzé kell tennie az OAuth metaadat-végpontjait az automatikus felderítéshez.

Felhasználónkénti OAuth-felhasználó–gép

Az OAuth felhasználónkénti hitelesítés lehetővé teszi az egyes felhasználói identitások hitelesítését és saját hitelesítő adatainak használatát az erőforrások eléréséhez. Minden felhasználó egyedi hozzáférési jogkivonatot ad ki, amely lehetővé teszi az egyéni hozzáférés-vezérlést, naplózást és elszámoltathatóságot. Ez a módszer akkor megfelelő, ha felhasználóspecifikus adathozzáférésre van szükség, és ha külső szolgáltatásokhoz fér hozzá az adott felhasználó nevében.

A külső szolgáltatásoknak meg kell felelniük az OAuth 2.0 specifikációinak

Az OAuthot használó HTTP-kapcsolatoknak olyan szolgáltatásokhoz kell csatlakozniuk, amelyek megfelelnek a hivatalos OAuth 2.0-specifikációnak a hozzáférési jogkivonat adatainak kezelésére és visszaadására vonatkozóan. Ez azt jelenti, hogy a szolgáltatás válaszainak a specifikációban leírt pontos mezőneveket és adatformátumokat kell használniuk, például access_token, expires_instb.

Ha problémákat tapasztal egy külső szolgáltatáshoz az OAuth 2.0 használatával, ellenőrizze, hogy a szolgáltatás válaszai megfelelnek-e ezeknek a követelményeknek.

Felügyelt OAuth-szolgáltatók

Kiválasztott szolgáltatók esetében az Azure Databricks kezeli az OAuth hitelesítéseket a háttérben, így nem regisztrálod saját OAuth alkalmazásodat. A kapcsolat létrehozásakor válassza az OAuth Felhasználó gépre felhasználónként lehetőséget, és válassza ki a szolgáltatót. A támogatott szolgáltatók konszolidált listájáért, konfigurációs jegyzeteiért és hatókörökükért lásd: Szolgáltatások menedzselt OAuth támogatással. Ha egy ügynököt az egyik szolgáltatóhoz MCP szerverként csatlakoztathatunk, regisztráljunk egy MCP szolgáltatást, amely ilyen kapcsolatot használ az autentifikáció kezelésére.

Kapcsolat létrehozása a külső szolgáltatással

Először hozzon létre egy Unity Catalog-kapcsolatot a külső szolgáltatással, amely megadja a szolgáltatás eléréséhez szükséges elérési utat és hitelesítő adatokat.

A Unity Catalog-kapcsolat használatának előnyei a következők:

• Hitelesítő adatok biztonságos kezelése: titkos kulcsok és jogkivonatok biztonságosan vannak tárolva és felügyelve a Unity Catalogban, biztosítva, hogy soha ne legyenek kitéve a felhasználók számára.
• Részletes hozzáférés-vezérlés: Unity Catalog lehetővé teszi a USE CONNECTION és MANAGE jogosultságokkal való kapcsolatok használatának és kezelésének részletes ellenőrzését.
• Gazdagép-specifikus jogkivonat-kényszerítés: A jogkivonatok a kapcsolat létrehozásakor megadott host_name gazdagéphez vannak korlátozva, biztosítva, hogy nem használhatók jogosulatlan gazdagépekkel.

Szükséges engedélyek: Metaadattár-rendszergazda vagy jogosultsággal CREATE CONNECTION rendelkező felhasználó.

Hozzon létre egy kapcsolatot az alábbi módszerek egyikével:

• Használja a Katalóguskezelő felhasználói felületét.
• Hajtsa végre a CREATE CONNECTION SQL-parancsot egy Azure Databricks jegyzetfüzetben vagy a Databricks SQL-lekérdezésszerkesztőben.
• Kapcsolat létrehozásához használja a Databricks REST API-t vagy a Databricks CLI-t. Lásd: POST /api/2.1/unity-catalog/connections és Unity Catalog parancsok.

Katalóguskezelő

Kapcsolat létrehozásához használja a Katalóguskezelő felhasználói felületét.

1. A Azure Databricks munkaterületen kattintson a Catalog elemre.

2. A Katalógus panel tetején kattintson a , majd válassza a Kapcsolat létrehozása lehetőséget a menüből.

3. Kattintson a Kapcsolat létrehozásaelemre.

4. Adjon meg egy felhasználóbarát kapcsolatnevet.

5. Válasszon egy kapcsolat típust az HTTPközül.

6. Válasszon Hitelesítési típust a következő lehetőségek közül:

   • Hozzáférési token
   • Dinamikus ügyfélregisztráció
   • OAuth gépről gépre
   • OAuth felhasználó és gép közötti megosztás
   • Felhasználónkénti OAuth-felhasználó–gép
     • Válassza a Manuális konfiguráció lehetőséget a saját OAuth-hitelesítő adatainak megadásához. Ahhoz, hogy a Databricks kezelje az OAuth hitelesítő adatokat egy támogatott szolgáltató számára, lásd : Kezelt OAuth szolgáltatók.

7. A Hitelesítési lapon adja meg a HTTP-kapcsolat alábbi kapcsolati tulajdonságait.

   Bearer token tulajdonságai

   Hordozó token esetén:

   Ingatlan	Leírás	Példaérték
   Házigazda	A Databricks-munkaterület vagy -üzembe helyezés alap URL-címe.	https://databricks.com
   Kikötő	A kapcsolathoz használt hálózati port, általában 443 HTTPS esetén.	443
   Tulajdonosi jogkivonat	Az API-kérések engedélyezéséhez használt hitelesítési jogkivonat.	bearer-token
   Alapértelmezett útvonal	Az API-végpontok gyökérútvonala.	/api/

   Dinamikus ügyfélregisztrációs tulajdonságok

   Dinamikus ügyfélregisztráció esetén:

   Ingatlan	Leírás
   Házigazda	A külső szolgáltatás HTTPS-URL-címe. A Databricks ezen URL-cím használatával felderíti az OAuth engedélyezési kiszolgálót, és automatikusan regisztrál egy ügyfelet.
   Kikötő	A kapcsolathoz használt hálózati port, általában 443 HTTPS esetén.
   Alapértelmezett útvonal	Az API-végpontok gyökérútvonala.
   OAuth-hatókör	(Nem kötelező) A felhasználói engedélyezés során megadni kívánt hatókör. Szóközzel elválasztott, kis- és nagybetűkre érzékeny karakterláncok listájaként fejeződik ki. Ha nincs megadva, a kiszolgáló határozza meg az alapértelmezett hatóköröket.

   OAuth gépi-gépi tulajdonságok

   OAuth machine-to-machine esetén:

   Ingatlan	Leírás
   Ügyfélazonosító	A létrehozott alkalmazás egyedi azonosítója.
   Titkos ügyfélkód	A létrehozott alkalmazáshoz létrehozott titkos kód vagy jelszó.
   OAuth-hatókör	A felhasználói engedélyezés során megadni kívánt hatókör. A hatókörparaméter szóközzel elválasztott, kis- és nagybetűket megkülönböztető karakterláncok listájaként van kifejezve. Például: channels:read channels:history chat:write
   Token végpont	Az ügyfél hozzáférési jogkivonatot szerezhet azáltal, hogy bemutatja az engedélyezési jogkivonatát vagy a frissítési jogkivonatát. Általában a következő formátumban: https://authorization-server.com/oauth/token

   OAuth Felhasználó–gép megosztott tulajdonságok

   OAuth felhasználó–gép megosztott esetén:

   • A rendszer kérni fogja, hogy jelentkezzen be OAuth-hitelesítő adataival. A használt hitelesítő adatokat bárki megosztja, aki ezt a kapcsolatot használja. Egyes szolgáltatóknak engedélyezési listát kell megadniuk az átirányítási URL-címhez, kérjük, adja meg <databricks_workspace_url>/login/oauth/http.html az átirányítási URL-engedélyezési listát. Példa: https://databricks.com/login/oauth/http.html

   Ingatlan	Leírás
   Ügyfélazonosító	A létrehozott alkalmazás egyedi azonosítója.
   Titkos ügyfélkód	A létrehozott alkalmazáshoz létrehozott titkos kód vagy jelszó.
   OAuth-hatókör	A felhasználói engedélyezés során megadni kívánt hatókör. A hatókörparaméter szóközzel elválasztott, kis- és nagybetűket megkülönböztető karakterláncok listájaként van kifejezve. Például: channels:read channels:history chat:write
   Engedélyezési végpont	Az erőforrás tulajdonosával való hitelesítésre szolgál a felhasználó-ügynök átirányításával. Általában a következő formátumban: https://authorization-server.com/oauth/authorize
   Token végpont	Az ügyfél hozzáférési jogkivonatot szerezhet azáltal, hogy bemutatja az engedélyezési jogkivonatát vagy a frissítési jogkivonatát. Általában a következő formátumban: https://authorization-server.com/oauth/token

   Felhasználónkénti OAuth felhasználó–gép tulajdonságok

   Felhasználónkénti OAuth-felhasználó:

   • A rendszer minden felhasználót arra kér, hogy a HTTP-kapcsolat első használatakor jelentkezzen be az egyéni OAuth-hitelesítő adataival. Egyes szolgáltatóknak engedélyezési listát kell megadniuk az átirányítási URL-címhez, kérjük, adja meg <databricks_workspace_url>/login/oauth/http.html az átirányítási URL-engedélyezési listát. Példa: https://databricks.com/login/oauth/http.html

   Ingatlan	Leírás
   Ügyfélazonosító	A létrehozott alkalmazás egyedi azonosítója. Az engedélyezési kiszolgáló használja az ügyfélalkalmazás azonosítására az OAuth-folyamat során.
   Titkos ügyfélkód	A létrehozott alkalmazáshoz létrehozott titkos kód vagy jelszó. Az ügyfélalkalmazás hitelesítésére szolgál a jogkivonatokra vonatkozó engedélyezési kódok cseréjekor, és bizalmasan kell kezelni.
   OAuth-hatókör	A felhasználói engedélyezés során megadni kívánt hatókör. Szóközökkel elválasztva, kis- és nagybetűket megkülönböztető sztringek listájaként kifejezve, amelyek meghatározzák az alkalmazás által kért engedélyeket. Például: channels:read channels:history chat:write
   Engedélyezési végpont	Az erőforrás tulajdonosának hitelesítésére szolgáló végpont, amely felhasználói ügynökön keresztül történő átirányítást és az engedélyezés megszerzését teszi lehetővé. Általában a következő formátumban: https://authorization-server.com/oauth/authorize Az ügyfél erre a végpontra irányítja a felhasználót, hogy jelentkezzen be, és hozzájáruljon az engedélyekhez.
   Token végpont	Az ügyfél által egy engedélyezési engedély (például egy engedélyezési kód) vagy egy hozzáférési jogkivonat frissítési jogkivonatának cseréjére használt végpont. Általában a következő formátumban: https://authorization-server.com/oauth/token
   Oauth hitelesítőadat-csere módszer	A szolgáltatók különböző módszereket igényelnek az OAuth-ügyfél hitelesítő adatainak átadásához a tokencsere során. Válasszon az alábbi lehetőségek közül: header_and_body: A hitelesítő adatokat az engedélyezési fejlécben és a kérelem törzsében is elhelyezi (alapértelmezett). body_only: A hitelesítő adatokat csak a kérelem törzsében helyezi el engedélyezési fejléc nélkül. header_only: A hitelesítő adatokat csak a hitelesítési fejlécben helyezi el (például az OKTA esetében).

8. Kattintson a Kapcsolat létrehozásaelemre.

SQL

Kapcsolat létrehozásához használja a CREATE CONNECTION SQL-parancsot.

Megjegyzés:

Az SQL-paranccsal nem hozhat létre OAuth machine-to-user shared kapcsolatot. Ehelyett tekintse meg a Catalog Explorer felhasználói felületének utasításait.

Ha új kapcsolatot szeretne létrehozni egy Tulajdonosi jogkivonathasználatával, futtassa a következő parancsot egy jegyzetfüzetben vagy a Databricks SQL-lekérdezésszerkesztőben:

CREATE CONNECTION <connection-name> TYPE HTTP
OPTIONS (
  host '<hostname>',
  port '<port>',
  base_path '<base-path>',
  bearer_token '<bearer-token>'
);

A Databricks a titkos adatok () használatát javasolja a bizalmas értékek, például hitelesítő adatok, egyszerű szöveges formában történő alkalmazása helyett (). Például:

CREATE CONNECTION <connection-name> TYPE HTTP
OPTIONS (
  host '<hostname>',
  port '<port>',
  base_path '<base-path>',
  bearer_token secret ('<secret-scope>','<secret-key-password>')
)

Ha új kapcsolatot szeretne létrehozni az OAuth Machine-to-Machine használatával, futtassa a következő parancsot egy jegyzetfüzetben vagy a Databricks SQL-lekérdezésszerkesztőben:

CREATE CONNECTION <connection-name> TYPE HTTP
OPTIONS (
  host '<hostname>',
  port '<port>',
  base_path '<base-path>',
  client_id '<client-id>',
  client_secret '<client-secret>',
  oauth_scope '<oauth-scope1> <oauth-scope-2>',
  token_endpoint '<token-endpoint>'
)

Unity Catalog-kapcsolat megosztása

Jogosultságok biztosítása USE CONNECTION a kapcsolat használatára jogosult személyazonossági jogok birtokosainak.

1. A munkaterületen lépjen a Katalógus>Kapcsolatok> elemhez a >engedélyek kezeléséhez.
2. Adjon megfelelő hozzáférést az identitások számára a Unity Catalog-kapcsolathoz.

Kérelmek továbbítása a HTTP-kapcsolatproxyn keresztül

Ha kérést szeretne küldeni egy külső szolgáltatásnak, a Databricks a HTTP-kapcsolatproxy használatát javasolja.

A Unity Catalog HTTP-kapcsolatproxy egy Databricks által üzemeltetett HTTP-végpont, amely az Ön nevében továbbítja a kéréseket külső szolgáltatásoknak. Ahelyett, hogy hitelesítési jogkivonatokat kezel az alkalmazásban, a Databricks használatával hitelesíthet, és lehetővé teszi, hogy a Databricks automatikusan injektálja a külső szolgáltatás hitelesítő adatait a Unity Catalog-kapcsolatból.

Ez akkor hasznos, ha:

• Külső REST API-t vagy MCP-kiszolgálót kell meghívnia egy Databricksen kívül futó alkalmazásból anélkül, hogy közvetlenül az alkalmazásban tárolnák a hitelesítő adatokat.
• Azt szeretné, hogy a Databricks kezelje a hitelesítő adatok tárolását, az OAuth-jogkivonat frissítését és a külső szolgáltatások felhasználónkénti hitelesítési folyamatait.
• Egy MCP-ügyfelet (például Claude Desktopot vagy Kurzort) egy külső MCP-kiszolgálóhoz csatlakoztat egy Databricks által felügyelt proxyn keresztül. Lásd: Külső MCP-kiszolgálók használata.

szükséges engedélyek:USE CONNECTION a kapcsolatobjektumon.

Proxy végpont URL

A proxyvégpont URL-címe a következő formátumot követi:

https://<workspace-hostname>/api/2.0/unity-catalog/connections/<connection-name>/proxy[/<sub-path>]

Paraméter	Leírás
<connection-name>	A Unity Catalog HTTP-kapcsolat neve.
<sub-path>	Opcionális. A kimenő URL-cím létrehozásakor a kapcsolat base_path után hozzáfűzött elérésiút-szegmens. Kihagyja a kapcsolat alap URL-címének közvetlen meghívását.

Hogyan hozza létre a proxy a kimenő kérést?

A proxy egyesíti a kapcsolat gazdagépét és base_path a kérés alútvonalát a külső szolgáltatásnak küldött URL-cím létrehozásához:

{connection host}{base_path}{sub-path}

Ha például a kapcsolat gazdagéppel https://api.example.com és alapútvonallal /v1van konfigurálva, a következő kérést kell megadnia:

POST /api/2.0/unity-catalog/connections/my_connection/proxy/messages

Továbbítása a következőre történik:

POST https://api.example.com/v1/messages

Fejléc továbbítása

A proxy a következő szabályokkal továbbítja a kérésfejléceket a külső szolgáltatásnak:

• Blokkolt fejlécek: A belső Azure Databricks fejlécek (például Authorization, Cookie, X-Databricks-* és hasonló munkamenetfejlécek) a továbbítás előtt törlődnek, hogy ne szivárogjanak ki Azure Databricks hitelesítő adatok a külső szolgáltatásokba.
• A rendszer az összes többi megadott fejlécet változatlanul továbbítja a külső szolgáltatásnak. Ezzel átadhatja a szolgáltatásspecifikus fejléceket, például Content-Type a külső szolgáltatás által igényelt egyéni API-kulcsokat.

Kérés tartalma

A kérelem törzse módosítás nélkül, változtatás nélkül továbbítva van a külső szolgáltatásnak.

Támogatott HTTP-metódusok

GET, POST, PUT, PATCH, , DELETE

Authentication

A proxyvégponttal szabványos Azure Databricks hitelesítéssel (személyes hozzáférési jogkivonat vagy OAuth) hitelesíthet. Azure Databricks ezután lekéri a Unity-katalógus kapcsolatában tárolt külső szolgáltatás hitelesítő adatait, és beszúrja őket a kimenő kérésbe. Minden kapcsolati hitelesítési típus (Bearer token, OAuth M2M, OAuth U2M Shared, OAuth U2M per user) támogatott. Lásd a külső szolgáltatások hitelesítési módszereit.

Example

Az alábbi példa post-kérelmet küld a proxyn keresztül egy Slack API-végpontnak. A Slack hordozó jogkivonata a slack_connection Unity Catalog-kapcsolatban van tárolva, és soha nem szerepel a kliens kérésében.

curl -X POST \
  "https://<workspace-hostname>/api/2.0/unity-catalog/connections/slack_connection/proxy/chat.postMessage" \
  -H "Authorization: Bearer <databricks-token>" \
  -H "Content-Type: application/json" \
  -d '{"channel": "C123456", "text": "Hello from Databricks!"}'

Ha slack_connection gazdagéppel https://slack.com és alapútvonallal /api van konfigurálva, ez a kérés https://slack.com/api/chat.postMessage továbbítva lesz, és a Slack hitelesítő adatait az Azure Databricks automatikusan beszúrja.

HTTP-kérés küldése a következő használatával: http_request

Figyelmeztetés

http_request már nem ajánlott. Használja a Unity Catalog kapcsolatok proxyvégpontját a szolgáltató SDK-jával az új kódhoz.

HTTP-kérések küldése a szolgáltatásnak a http_request beépített SQL-függvény használatával.

szükséges engedélyek:USE CONNECTION a kapcsolatobjektumon.

Futtassa a következő SQL-parancsot egy jegyzetfüzetben vagy a Databricks SQL-szerkesztőben. Cserélje le a helyettesítő értékeket.

• connection-name: A kapcsolati objektum, amely meghatározza a gazdagépet, a portot, az alap elérési utat és a hozzáférési hitelesítő adatokat.
• http-method: A hívás indításához használt HTTP-kérési módszer. Például: GET, POST, PUT, DELETE
• path: A szolgáltatáserőforrás meghívásához szükséges base_path utáni összefűzési útvonal.
• json: A kérelemmel küldendő JSON-törzs.
• headers: A kérelemfejlécek megadására vonatkozó térkép.

SELECT http_request(
  conn => <connection-name>,
  method => <http-method>,
  path => <path>,
  json => to_json(named_struct(
    'text', text
  )),
  headers => map(
    'Accept', "application/vnd.github+json"
  )
);

Megjegyzés:

A http_request használatával az SQL-hozzáférés le van tiltva a Felhasználó-ról Gépre Felhasználónként és Dinamikus Ügyfélregisztrációs kapcsolattípusok esetében. Ehelyett használja a Python Databricks SDK-t.

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.serving import ExternalFunctionRequestHttpMethod

WorkspaceClient().serving_endpoints.http_request(
  conn="connection-name",
  method=ExternalFunctionRequestHttpMethod.POST,
  path="/api/v1/resource",
  json={"key": "value"},
  headers={"extra-header-key": "extra-header-value"},
)

HTTP-kapcsolatok használata ügynökeszközökhöz

A HTTP kapcsolatok az alapot képezik annak, hogy az ügynököket külső eszközökhöz, például a Slackhez, a Google Naptárhoz vagy bármely API-val rendelkező szolgáltatáshoz kapcsolják. Az ügynök csatlakoztatásához egy külső MCP szerverhez regisztráljon egy MCP szolgáltatást, amely sémaszintű HTTP kapcsolatot használ az autentifikáció kezelésére. Közvetlenül ügynök kódból való REST API-k hívásához használja a connections proxyt.

Biztosítsa hálózati kapcsolatát a külső szolgáltatásokhoz

Azure Databricks HTTP-kapcsolatok forgalmát a munkaterület kiszolgáló nélküli számítási síkján keresztül irányítja külső szolgáltatásokhoz. Ezt a forgalmat Private Link vagy IP-engedélyezési listával lehet biztonságossá tenni.

Private Link (ajánlott)

Private Link teljes bérlői elkülönítést biztosít. A kapcsolaton keresztül csak a Azure Databricks munkaterület érheti el a szolgáltatást. A forgalom privát kapcsolaton keresztül halad a nyilvános internet helyett. Használja a Private Link a felhőhálózaton (VPC vagy VNet) üzemeltetett külső szolgáltatásokhoz.

A Private Link konfigurálásához lásd: Konfigurálja a virtuális hálózat erőforrásaihoz való privát kapcsolatot. A proxybeállítási mintákért lásd a Private és Dedikált Kapcsolati Minták az Azure Databricks kiszolgáló nélküli megoldásokhoz blogsorozatot.

IP-engedélyezési lista

Ha a Private Link nem lehetséges, konfigurálja a külső szolgáltatás tűzfalszabályait úgy, hogy a Azure Databricks kiszolgáló nélküli kimenő IP-címeket felvegye a listára. Az IP-engedélyezéssel a kimenő IP-címek Azure Databricks ügyfelek között vannak megosztva, így ez a megközelítés nem biztosít bérlői elkülönítést.

A kiszolgáló nélküli kimenő IP-címekről, valamint az engedélyezési listára helyezésükre vonatkozó útmutatásért lásd: Configure a firewall for serverless compute access.

Megjegyzés:

HTTP-kapcsolatok használata Azure Databricks adatátviteli díjakat vonhat maga után. További információ: Adatátviteli és kapcsolati díjszabás.

Limitations

• A http_request függvény sebessége korlátozott. Interaktív és ügynökalapú használati esetekre tervezték, nem nagy mennyiségű kötegelt lekérdezésekhez. Ha a http_request műveletet egyetlen lekérdezésen belül sok soron futtatja, előfordulhat, hogy a kérések korlátozás alá esnek, és ez hibákat okozhat. Ennek megkerüléséhez használja a Databricks SDK for Python eszközt arra, hogy a kéréseket kisebb kötegekben, közöttük szünetet tartva küldje el. Az új kódhoz a Databricks azt javasolja, hogy a szolgáltató SDK-jával a Unity Catalog-kapcsolatok proxyvégpontját használja http_request helyett.

További erőforrások

• Regisztráció : Regisztrálj egy külső MCP szervert , hogy az ügynököket külső MCP szerverekhez köthesd.

• Biztosítsd hálózati kapcsolatodat a külső szolgáltatásokhoz Private Link vagy IP allowlisting-szel.