Tworzenie łączników danych bez kodu ściągania przy użyciu zagnieżdżonego sondowania interfejsu API

Niektóre interfejsy API REST wymagają sekwencyjnych wywołań, w których odpowiedź z jednego punktu końcowego zapewnia dane wejściowe, które muszą zostać przekazane do innego punktu końcowego. Program Microsoft Sentinel Codeless Connector Framework (CCF) obsługuje ten wzorzec za pomocą zagnieżdżonego sondowania interfejsu API dla RestApiPoller łączników.

Ważna

Zagnieżdżone odpytywanie API jest obecnie dostępne w publicznej wersji zapoznawczej. Dodatkowe warunki Azure Preview zawierają więcej warunków prawnych dotyczących funkcji Azure w wersji beta, preview lub w innych przypadkach, które nie są jeszcze dostępne ogólnie.

Użyj zagnieżdżonego odpytywania API, gdy nadrzędne wywołanie API zwraca identyfikatory, kursory lub inne wartości wymagane przez jedno lub więcej podrzędnych wywołań API. Program CCF wyodrębnia wymagane wartości z odpowiedzi nadrzędnej, podstawi je do żądania podrzędnego i wysyła odpowiedzi podrzędne do skonfigurowanej tabeli docelowej.

Skonfiguruj zagnieżdżone odpytywanie interfejsu API w łączniku CCF pull, definiując logikę zagnieżdżania w regułach połączeń RestApiPoller.

Aby zapoznać się z całym procesem tworzenia i pakowania łącznika CCF, zobacz Tworzenie łącznika bezkodowego dla Microsoft Sentinel. Możesz także użyć rozszerzenia Microsoft Sentinel dla programu Visual Studio Code, aby wdrażać i testować zagnieżdżone przepływy pracy sondowania interfejsu API. Informacje o konfiguracji i użytkowaniu można znaleźć w artykule Buduj niestandardowe złącza z AI w Microsoft Sentinel. Informacje o standardowych właściwościach RestApiPoller żądania, odpowiedzi, uwierzytelniania, stronicowania i DCR można znaleźć w dokumencie Informacje o regułach połączenia łącznika danych RestApiPoller.

Uwaga / Notatka

Jeśli jesteś niezależnym dostawcą oprogramowania (ISV) tworzącym integrację Microsoft Sentinel przy użyciu struktury łączników bez użycia kodu, zespół Microsoft App Assure może być w stanie pomóc. Aby zaangażować zespół usługi App Assure, wyślij wiadomość e-mail na azuresentinelpartner@microsoft.comadres .

Wymagania wstępne

Przed skonfigurowaniem zagnieżdżonego sondowania interfejsu API upewnij się, że rozumiesz następujące kwestie:

Punkty końcowe interfejsu API, które łącznik musi wywołać.
Które wartości odpowiedzi z nadrzędnego wywołania interfejsu API są wymagane przez podrzędne wywołanie interfejsu API.
Schemat wyjściowy tabeli docelowej.
Jak utworzyć standardowy łącznik CCF RestApiPoller .

Kompletny łącznik CCF zawiera następujące składniki:

Tabela: tabela niestandardowa Log Analytics, w której są przechowywane pozyskane dane.
DCR: reguła gromadzenia danych, która definiuje transformację pozyskiwania danych.
Interfejs użytkownika łącznika: definicja łącznika danych wyświetlana w centrum zawartości Microsoft Sentinel.
Reguły połączeń danych: konfiguracja łącznika, która pobiera dane ze źródłowego interfejsu API.

Sondowanie zagnieżdżonego interfejsu API jest konfigurowane w regułach połączenia danych dla łącznika RestApiPoller .

Co to jest sondowanie zagnieżdżonego interfejsu API?

Zagnieżdżone sondowanie interfejsu API to wzorzec sondowania CCF, który łączy sekwencyjnie wywołania interfejsu API REST. Pierwsze wywołanie interfejsu API, nazywane krokiem nadrzędnym, zwraca wartości wymagane przez późniejsze wywołania interfejsu API nazywane krokami podrzędnym.

Na przykład interfejs API może używać tego wzorca:

GET /incidents Zwraca listę identyfikatorów zdarzeń.
GET /incidents/{incidentId}/details zwraca pełny rekord incydentu dla każdego identyfikatora.

Pojedyncze wywołanie interfejsu API nie zwraca pełnych danych. Łącznik musi wywołać punkt końcowy listy, wyodrębnić każdy incidentIdelement , a następnie wywołać punkt końcowy szczegółów raz dla każdego identyfikatora.

Użyj sondowania zagnieżdżonego interfejsu API w przypadku:

Punkt końcowy listy zwraca identyfikatory zasobów, a punkt końcowy szczegółów wymaga każdego identyfikatora w ścieżce adresu URL lub ciągu zapytania.
Odpowiedź nadrzędna zwraca kursor, token sesji, identyfikator zapytania lub identyfikator odwołania wymagany przez podrzędne żądanie.
Odpowiedź zawiera tablicę wartości, które muszą być przekazywane indywidualnie do innego punktu końcowego.
Odpowiedź nadrzędna zawiera pola, które chcesz zachować, a odpowiedź podrzędna dodaje dane uzupełniające, które powinny zostać połączone w tym samym wierszu wynikowym.

Jeśli pojedyncze wywołanie interfejsu API zwraca wszystkie potrzebne dane, zagnieżdżone sondowanie interfejsu API nie jest wymagane. Użyj właściwości standardowej eventsJsonPaths , aby wyodrębnić rekordy z odpowiedzi.

Jak działa sondowanie zagnieżdżonego interfejsu API

Sondowanie zagnieżdżonego interfejsu API jest konfigurowane w następujących sekcjach:

Section	Lokalizacja	Purpose
`request`	Krok nadrzędny	Definiuje nadrzędne żądanie interfejsu API. Właściwości okna czasowego są skonfigurowane tutaj.
`response`	Krok nadrzędny	Definiuje sposób wyodrębniania rekordów z odpowiedzi nadrzędnej.
`stepInfo`	Krok nadrzędny	Włącza zagnieżdżone sondowanie i definiuje kroki podrzędne do uruchomienia w następnej kolejności.
`stepCollectorConfigs`	Krok nadrzędny	Definiuje każdy krok podrzędny, w tym żądanie podrzędne i obsługę odpowiedzi.
`shouldJoinNestedData`	Krok podrzędny	Określa, czy odpowiedź podrzędna zastępuje nadrzędne dane wyjściowe, czy jest przyłączona do rekordu nadrzędnego.

Zagnieżdżony przebieg odpytywania działa w następujący sposób:

Żądanie nadrzędne jest uruchomione.
Odpowiedź nadrzędna jest dzielona na rekordy za pomocą response.eventsJsonPaths.
stepPlaceholdersParsingKql wyodrębnia wartości zastępcze z każdego rekordu nadrzędnego.
CCF podstawia symbole zastępcze w konfiguracji kroku podrzędnego.
Program CCF uruchamia żądania podrzędne.
Odpowiedź podrzędna jest wysyłana jako wiersz wyjściowy lub przyłączona do rekordu nadrzędnego w zależności od wartości shouldJoinNestedData.

Szkielet konfiguracji zagnieżdżonego odpytywania

Poniższy przykład przedstawia strukturę zagnieżdżonego RestApiPoller łącznika. Standardowe właściwości CCF są skracane za pomocą ....

{
  "kind": "RestApiPoller",
  "properties": {
    "connectorDefinitionName": "...",
    "dcrConfig": { },
    "dataType": "...",
    "auth": { },
    "request": {
      "apiEndpoint": "https://api.example.com/incidents",
      "httpMethod": "GET",
      "queryWindowInMin": 60,
      "queryTimeFormat": "yyyy-MM-ddTHH:mm:ssZ",
      "startTimeAttributeName": "startTime",
      "endTimeAttributeName": "endTime"
    },
    "response": {
      "eventsJsonPaths": [ "$.incidents" ],
      "format": "json"
    },
    "stepInfo": {
      "stepType": "Nested",
      "nextSteps": [
        {
          "stepId": "fetchIncidentDetails",
          "stepPlaceholdersParsingKql": "source | project res = parse_json(data) | project incidentId = res.incidentId"
        }
      ]
    },
    "stepCollectorConfigs": {
      "fetchIncidentDetails": {
        "shouldJoinNestedData": false,
        "request": {
          "httpMethod": "GET",
          "apiEndpoint": "https://api.example.com/incidents/$incidentId$/details"
        },
        "response": {
          "eventsJsonPaths": [ "$" ],
          "format": "json"
        }
      }
    }
  }
}

Właściwości zagnieżdżonego odpytywania

Majątek	Lokalizacja	Description
`stepInfo.stepType`	Krok nadrzędny	Musi być ustawiona na `Nested`, aby włączyć zagnieżdżone odpytywanie API.
`stepInfo.nextSteps[].stepId`	Krok nadrzędny	Nazwa kroku podrzędnego. Ta wartość musi być zgodna z kluczem w pliku `stepCollectorConfigs`.
`stepInfo.nextSteps[].stepPlaceholdersParsingKql`	Krok nadrzędny	KQL, który wyodrębnia wartości z odpowiedzi nadrzędnej. Zapytanie jest wykonywane na `source`, gdzie kolumna `data` zawiera każdy rekord nadrzędny w postaci surowego ciągu JSON. Każda rzutowana kolumna staje się symbolem zastępczym.
`stepCollectorConfigs`	Krok nadrzędny	Mapa definicji kroków podrzędnych, w której kluczami są wartości `stepId` zadeklarowane w `stepInfo.nextSteps`.
`shouldJoinNestedData`	Krok podrzędny	Określa sposób dostarczania odpowiedzi podrzędnej do strumienia. Ustaw na `false`, gdy odpowiedź elementu podrzędnego zawiera pełny rekord wyjściowy. Ustaw wartość `true`, gdy potrzebujesz pól zarówno z odpowiedzi nadrzędnej, jak i podrzędnej w tym samym wierszu wyjściowym.
`joinedDataStepName`	Krok podrzędny	Nazwa kolumny `dynamic`, w której jest przechowywana dołączona odpowiedź podrzędna, gdy `shouldJoinNestedData` ma wartość `true`. Nie jest używany, gdy `shouldJoinNestedData` ma wartość `false`.

Zastępowanie symboli zastępczych

Symbole zastępcze są wyodrębniane przez stepPlaceholdersParsingKql, a odwołania do nich używają składni $placeholderName$ .

Na przykład to zapytanie KQL tworzy symbol zastępczy o nazwie incidentId:

source
| project res = parse_json(data)
| project incidentId = res.incidentId

Krok podrzędny może następnie odwoływać się do symbolu wieloznacznego w postaci $incidentId$ :

"apiEndpoint": "https://api.example.com/incidents/$incidentId$/details"

Substytucja symboli zastępczych jest obsługiwana w całej konfiguracji kroku podrzędnego, w tym w żądaniu podrzędnym apiEndpoint, headers, queryParameters i queryParametersTemplate.

Konfigurowanie właściwości żądania podrzędnego

Blok request wewnątrz kroku podrzędnego obsługuje typowe właściwości żądania stosowane przy odpytywaniu API.

Typowe właściwości żądania podrzędnego obejmują:

Majątek	Description
`apiEndpoint`	Podrzędny punkt końcowy interfejsu API. Możesz uwzględnić symbole zastępcze, takie jak $incidentId$ .
`httpMethod`	Metoda HTTP dla żądania podrzędnego, na przykład `GET` lub `POST`.
`headers`	Nagłówki żądania dla podrzędnego wywołania API. Zastępowanie symboli zastępczych jest obsługiwane.
`queryParameters`	Parametry ciągu zapytania dla podrzędnego wywołania interfejsu API. Zastępowanie symboli zastępczych jest obsługiwane.
`queryParametersTemplate`	Szablon używany w scenariuszach treści żądania lub ładunku zapytania. Zastępowanie symboli zastępczych jest obsługiwane.
`isPostPayloadJson`	Ustaw wartość na `true` , gdy ładunek POST powinien być wysyłany jako JSON.
`rateLimitQPS`	Maksymalna liczba żądań na sekundę.
`rateLimitConfig`	Konfiguracja limitu szybkości, która może używać nagłówków limitu szybkości zwracanych przez interfejs API.
`retryCount`	Liczba ponownych prób. Wartość domyślna: `3`. Obsługiwany zakres: `1` do `6`.
`timeoutInSeconds`	Limit czasu oczekiwania na żądanie w sekundach. Wartość domyślna: `20`. Obsługiwany zakres: `1` do `180`.

Żądanie nadrzędne określa okno czasowe odpytywania. Skonfiguruj właściwości okna czasowego, takie jak queryWindowInMin, queryTimeFormat, startTimeAttributeNamei endTimeAttributeName tylko w żądaniu nadrzędnym. Kroki podrzędne są zwykle oparte na wartościach zastępczych wyodrębnionych z odpowiedzi nadrzędnej.

Konfigurowanie równoległości żądań podrzędnych

maxParallelism określa liczbę wywołań podrzędnych, które mogą być uruchamiane współbieżnie. Wartość domyślna to 15.

maxParallelism nie jest częścią standardowej konfiguracji łącznika nadrzędnego i nie można jej ustawić w kroku nadrzędnym. Ponieważ kroki podrzędne są przekazywane dalej bez tłumaczenia nazw pól, w razie potrzeby można ustawić maxParallelism wewnątrz bloku request kroku podrzędnego.

"stepCollectorConfigs": {
  "fetchIncidentDetails": {
    "shouldJoinNestedData": false,
    "request": {
      "httpMethod": "GET",
      "apiEndpoint": "https://api.contoso.com/incidents/$incidentId$/details",
      "maxParallelism": 15
    },
    "response": {
      "eventsJsonPaths": [ "$" ],
      "format": "json"
    }
  }
}

Wybierz, czy chcesz połączyć dane nadrzędne i podrzędne

Użyj shouldJoinNestedData, aby kontrolować sposób, w jaki odpowiedzi podrzędne są dostarczane do strumienia.

Użyj `shouldJoinNestedData: false`

Ustaw shouldJoinNestedData na false, jeśli odpowiedź elementu nadrzędnego zawiera tylko wartości wymagane dla żądania elementu podrzędnego, a odpowiedź elementu podrzędnego zawiera pełny rekord, który chcesz zaimportować.

Na przykład użyj polecenia false , gdy:

Nadrzędne wywołanie zwraca tylko identyfikatory incydentów.
Wywołanie podrzędne zwraca pełne rekordy incydentów.
Nie musisz zachowywać żadnych pól nadrzędnych w wierszu docelowym.

"stepCollectorConfigs": {
  "fetchIncidentDetails": {
    "shouldJoinNestedData": false,
    "request": {
      "httpMethod": "GET",
      "apiEndpoint": "https://api.contoso.com/incidents/$incidentId$/details"
    },
    "response": {
      "eventsJsonPaths": [ "$" ],
      "format": "json"
    }
  }
}

Użyj `shouldJoinNestedData: true`

Ustaw shouldJoinNestedData na true, gdy potrzebujesz pól zarówno z odpowiedzi nadrzędnej, jak i z odpowiedzi podrzędnej w tym samym wierszu docelowym.

Na przykład użyj polecenia true , gdy:

Nadrzędne wywołanie zwraca pola alertu, takie jak identyfikator alertu, poziom ważności i czas wykrycia.
Wywołanie podrzędne zwraca pola uzupełniające, takie jak użytkownik, którego dotyczy zdarzenie, źródłowy adres IP lub geolokalizacja.
Przekształcenie DCR musi odwzorowywać zarówno pola nadrzędne, jak i podrzędne w tabeli docelowej.

Gdy parametr shouldJoinNestedData ma wartość true, ustaw joinedDataStepName na nazwę kolumny dynamic, która przechowuje odpowiedź elementu podrzędnego.

"stepCollectorConfigs": {
  "fetchAlertEnrichment": {
    "shouldJoinNestedData": true,
    "joinedDataStepName": "enrichment",
    "request": {
      "httpMethod": "GET",
      "apiEndpoint": "https://api.contoso.com/alerts/$alertId$/enrichment"
    },
    "response": {
      "eventsJsonPaths": [ "$" ],
      "format": "json"
    }
  }
}

Przykład: żądanie podrzędne GET

W tym przykładzie użyto dwuetapowego interfejsu API zdarzeń firmy Contoso:

Żądanie nadrzędne wywołuje GET /incidents i otrzymuje listę identyfikatorów incydentów.
stepPlaceholdersParsingKql wyodrębnia incidentId z każdego rekordu nadrzędnego.
Żądanie podrzędne wywołuje GET /incidents/$incidentId$/details raz dla każdego identyfikatora incydentu.
Podrzędne odpowiedzi są wysyłane do strumienia jako rekordy płaskie.

Odpowiedź główna

{
  "incidents": [
    { "incidentId": "INC-001" },
    { "incidentId": "INC-002" },
    { "incidentId": "INC-003" }
  ]
}

Odpowiedź podrzędna

{
  "incidentId": "INC-001",
  "title": "Suspicious login attempt",
  "severity": "High",
  "status": "Active",
  "createdAt": "2026-05-30T14:22:00Z",
  "affectedUser": "alice@contoso.com",
  "sourceIp": "198.51.100.42"
}

Konfiguracja sondowania

{
  "kind": "RestApiPoller",
  "properties": {
    "connectorDefinitionName": "ContosoIncidentsConnector",
    "dcrConfig": {
      "dataCollectionEndpoint": "{{dataCollectionEndpoint}}",
      "dataCollectionRuleImmutableId": "{{dataCollectionRuleImmutableId}}",
      "streamName": "Custom-ContosoIncidents_CL"
    },
    "dataType": "ContosoIncidents_CL",
    "auth": {
      "type": "APIKey",
      "ApiKey": "{{apiKey}}",
      "ApiKeyName": "x-functions-key"
    },
    "request": {
      "apiEndpoint": "https://api.contoso.com/incidents",
      "httpMethod": "GET",
      "queryWindowInMin": 60,
      "queryTimeFormat": "yyyy-MM-ddTHH:mm:ssZ",
      "startTimeAttributeName": "startTime",
      "endTimeAttributeName": "endTime",
      "headers": {
        "Accept": "application/json"
      }
    },
    "response": {
      "eventsJsonPaths": [ "$.incidents" ],
      "format": "json"
    },
    "stepInfo": {
      "stepType": "Nested",
      "nextSteps": [
        {
          "stepId": "fetchIncidentDetails",
          "stepPlaceholdersParsingKql": "source | project res = parse_json(data) | project incidentId = res.incidentId"
        }
      ]
    },
    "stepCollectorConfigs": {
      "fetchIncidentDetails": {
        "shouldJoinNestedData": false,
        "request": {
          "httpMethod": "GET",
          "apiEndpoint": "https://api.contoso.com/incidents/$incidentId$/details",
          "headers": {
            "Accept": "application/json"
          },
          "retryCount": 3,
          "timeoutInSeconds": 60
        },
        "response": {
          "eventsJsonPaths": [ "$" ],
          "format": "json"
        }
      }
    }
  }
}

Przykład: żądanie podrzędne POST z treścią JSON

Niektóre interfejsy API wymagają, aby identyfikatory z odpowiedzi nadrzędnej zostały wysłane w treści POST zamiast ścieżki adresu URL lub ciągu zapytania. Użyj queryParametersTemplate z isPostPayloadJson dla tego wzorca.

W tym przykładzie odpowiedź elementu nadrzędnego zwraca element incidentId, a żądanie elementu podrzędnego wysyła tę wartość w treści żądania POST w formacie JSON.

"stepCollectorConfigs": {
  "fetchIncidentDetails": {
    "shouldJoinNestedData": false,
    "request": {
      "httpMethod": "POST",
      "apiEndpoint": "https://api.contoso.com/incidents/details:batchGet",
      "headers": {
        "Accept": "application/json",
        "Content-Type": "application/json"
      },
      "queryParametersTemplate": "{'ids': ['$incidentId$']}",
      "isPostPayloadJson": true,
      "retryCount": 3,
      "timeoutInSeconds": 60
    },
    "response": {
      "eventsJsonPaths": [ "$.items" ],
      "format": "json"
    }
  }
}

Przykład: Dołączanie danych wzbogacania podrzędnego do rekordu nadrzędnego

W tym przykładzie użyto interfejsu API alertów firmy Contoso, w którym odpowiedź główna zawiera pola, które należy zachować, a odpowiedź podrzędna zawiera dane wzbogacające.

Odpowiedź główna

{
  "alerts": [
    {
      "alertId": "ALT-001",
      "severity": "High",
      "detectedAt": "2026-05-30T14:22:00Z",
      "riskScore": 92
    }
  ]
}

Odpowiedź podrzędna

{
  "alertId": "ALT-001",
  "affectedUser": "bob@contoso.com",
  "sourceIp": "198.51.100.77",
  "geolocation": "US/Virginia",
  "relatedIncidentId": "INC-042"
}

Konfiguracja sondowania

{
  "kind": "RestApiPoller",
  "properties": {
    "connectorDefinitionName": "ContosoAlertsConnector",
    "dcrConfig": {
      "dataCollectionEndpoint": "{{dataCollectionEndpoint}}",
      "dataCollectionRuleImmutableId": "{{dataCollectionRuleImmutableId}}",
      "streamName": "Custom-ContosoAlerts_CL"
    },
    "dataType": "ContosoAlerts_CL",
    "auth": {
      "type": "APIKey",
      "ApiKey": "{{apiKey}}",
      "ApiKeyName": "x-functions-key"
    },
    "request": {
      "apiEndpoint": "https://api.contoso.com/alerts",
      "httpMethod": "GET",
      "queryWindowInMin": 60,
      "queryTimeFormat": "yyyy-MM-ddTHH:mm:ssZ",
      "startTimeAttributeName": "startTime",
      "endTimeAttributeName": "endTime"
    },
    "response": {
      "eventsJsonPaths": [ "$.alerts" ],
      "format": "json"
    },
    "stepInfo": {
      "stepType": "Nested",
      "nextSteps": [
        {
          "stepId": "fetchAlertEnrichment",
          "stepPlaceholdersParsingKql": "source | project res = parse_json(data) | project alertId = res.alertId"
        }
      ]
    },
    "stepCollectorConfigs": {
      "fetchAlertEnrichment": {
        "shouldJoinNestedData": true,
        "joinedDataStepName": "enrichment",
        "request": {
          "httpMethod": "GET",
          "apiEndpoint": "https://api.contoso.com/alerts/$alertId$/enrichment"
        },
        "response": {
          "eventsJsonPaths": [ "$" ],
          "format": "json"
        }
      }
    }
  }
}

Przekształcenie DCR może następnie rzutować pola zarówno z rekordu nadrzędnego, jak i z dołączonej odpowiedzi podrzędnej.

Przykład:

source
| extend enrichment = todynamic(enrichment)
| project
    TimeGenerated = todatetime(detectedAt),
    AlertId = tostring(alertId),
    Severity = tostring(severity),
    RiskScore = toint(riskScore),
    AffectedUser = tostring(enrichment.affectedUser),
    SourceIp = tostring(enrichment.sourceIp),
    Geolocation = tostring(enrichment.geolocation),
    RelatedIncidentId = tostring(enrichment.relatedIncidentId)

Uwierzytelnianie kroku podrzędnego i nazwy pól stronicowania

Tłumaczenie nazwy pola dotyczy tylko kroku nadrzędnego. Każdy wpis w pliku stepCollectorConfigs jest przekazywany dosłownie i nie jest mapowany ponownie. W związku z tym wszystkie auth lub paging bloki wewnątrz kroku podrzędnego muszą używać nazw pól kroków podrzędnych pokazanych w poniższych tabelach.

Pola uwierzytelniania

Nazwa pola kroku nadrzędnego	Nazwa pola kroku podrzędnego
`type`	`AuthType`
`apiKey`	`APIKey`
`apiKeyName`	`APIKeyName`
`redirectUri` dla protokołu OAuth2	`RedirectionEndpoint`
`isCredentialsInHeaders` dla protokołu OAuth2 lub JWT	`IsClientSecretInHeader`
`grantType` dla protokołu OAuth2	`FlowName`
`queryParameters` dla JWT	`TokenEndpointQueryParameters`
`isJsonRequest` dla JWT	`IsTokenEndpointPostPayloadJson`
`userName` / `password` pary klucz-wartość do uwierzytelniania JWT lub sesji	`UsernameAttributeName` i `UsernameAttributeValue` / `PasswordAttributeName` i `PasswordAttributeValue`

W przypadku protokołu OAuth2 wartość FlowName jest również przekształcana. Na przykład użyj polecenia ClientCredentials zamiast client_credentials, a AuthCode zamiast authorization_code.

Pola paginacji

Nazwa pola kroku nadrzędnego	Nazwa pola kroku podrzędnego
`pageSizeParameterName`	`pageSizeParaName`

Wszystkie inne nazwy pól stronicowania i odpowiedzi są takie same w przypadku kroków nadrzędnych i podrzędnych.

Limits

Sondowanie zagnieżdżonego interfejsu API ma następujące limity:

Limit	Description
Podkroki `stepCollectorConfigs`	Konfiguracja zagnieżdżona obsługuje maksymalnie cztery wpisy w pliku `stepCollectorConfigs`.
Wpisy w `stepInfo.nextSteps`	`stepInfo.nextSteps` obsługuje maksymalnie trzy wpisy.
Odwołania cykliczne	Odwołania do kroków cyklicznych nie są obsługiwane i są odrzucane podczas walidacji.

Ukończ łącznik

Po skonfigurowaniu reguł zagnieżdżonego połączenia RestApiPoller skonfiguruj pozostałe składniki łącznika CCF:

Utwórz lub zaktualizuj tabelę docelową.
Utwórz DCR i transformację.
Utwórz definicję interfejsu użytkownika łącznika.
Umieść konektor w szablonie wdrożenia ARM.
Wdrażanie i testowanie łącznika.

Aby zapoznać się z całym procesem, zobacz Tworzenie bezkodowego łącznika dla usługi Microsoft Sentinel.

Opinia

Czy ta strona była pomocna?

Last updated on 2026-08-24

Tworzenie łączników danych bez kodu ściągania przy użyciu zagnieżdżonego sondowania interfejsu API

Wymagania wstępne

Co to jest sondowanie zagnieżdżonego interfejsu API?

Jak działa sondowanie zagnieżdżonego interfejsu API

Szkielet konfiguracji zagnieżdżonego odpytywania

Właściwości zagnieżdżonego odpytywania

Zastępowanie symboli zastępczych

Konfigurowanie właściwości żądania podrzędnego

Konfigurowanie równoległości żądań podrzędnych

Wybierz, czy chcesz połączyć dane nadrzędne i podrzędne

Użyj shouldJoinNestedData: false

Użyj shouldJoinNestedData: true

Przykład: żądanie podrzędne GET

Odpowiedź główna

Odpowiedź podrzędna

Konfiguracja sondowania

Przykład: żądanie podrzędne POST z treścią JSON

Przykład: Dołączanie danych wzbogacania podrzędnego do rekordu nadrzędnego

Odpowiedź główna

Odpowiedź podrzędna

Konfiguracja sondowania

Uwierzytelnianie kroku podrzędnego i nazwy pól stronicowania

Pola uwierzytelniania

Pola paginacji

Limits

Ukończ łącznik

Treści powiązane

Opinia

Dodatkowe zasoby

Użyj `shouldJoinNestedData: false`

Użyj `shouldJoinNestedData: true`