

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Requêtes fédérées SPARQL dans Neptune à l'aide de l'extension `SERVICE`
<a name="sparql-service"></a>

Amazon Neptune prend entièrement en charge l'extension de requête fédérée SPARQL qui utilise le mot-clé `SERVICE`. (Pour plus d'informations, consultez [Requête fédérée SPARQL 1.1](https://www.w3.org/TR/sparql11-federated-query/).)

Le mot-clé `SERVICE` indique au moteur de requête SPARQL qu'il doit exécuter une partie de la requête sur un point de terminaison SPARQL distant et composer le résultat de la requête finale. Seules les opérations `READ` sont possibles. Les opérations `WRITE` et `DELETE` ne sont pas prises en charge. Neptune ne peut exécuter des requêtes fédérées que sur des points de terminaison SPARQL accessibles au sein de son cloud privé virtuel (VPC). Toutefois, vous pouvez également utiliser un proxy inverse dans le VPC pour rendre une source de données externe accessible au sein du VPC.

**Note**  
Lorsque SPARQL `SERVICE` est utilisé pour fédérer une requête à deux clusters Neptune ou plus dans le même VPC, les groupes de sécurité doivent être configurés pour autoriser tous ces clusters Neptune à communiquer entre eux.

**Important**  
La fonction SPARQL 1.1 Federation effectue des demandes de service en votre nom lorsqu'elle transmet des requêtes et des paramètres à des points de terminaison SPARQL externes. Il vous incombe de vérifier que les points de terminaison SPARQL externes répondent aux exigences de sécurité et de gestion des données de votre application.

## Exemple de requête fédérée Neptune
<a name="sparql-service-example-1"></a>

L'exemple simple suivant montre le fonctionnement des requêtes fédérées SPARQL.

Supposons qu'un client envoie la requête suivante à *Neptune-1* à l'adresse `http://neptune-1:8182/sparql`.

```
SELECT * WHERE {
   ?person rdf:type foaf:Person .
   SERVICE <http://neptune-2:8182/sparql> {
       ?person foaf:knows ?friend .
    }
}
```

1. *Neptune-1* évalue le premier modèle de requête (*Q-1*) qui est `?person rdf:type foaf:Person`, utilise les résultats pour résoudre `?person` dans *Q-2* (`?person foaf:knows ?friend`) et transmet le modèle obtenu à *Neptune-2* à l'adresse `http://neptune-2:8182/sparql`.

1. *Neptune-2* évalue *Q-2* et renvoie les résultats à *Neptune-1*.

1. *Neptune-1* joint les solutions pour les deux modèles et renvoie les résultats au client.

Ce flux est illustré dans le diagramme suivant.

![\[Diagramme de flux illustrant les modèles de requêtes fédérées SPARQL évalués et les réponses renvoyées au client.\]](http://docs.aws.amazon.com/fr_fr/neptune/latest/userguide/images/federated.png)


**Note**  
« Par défaut, l'optimiseur détermine à quel moment de l'exécution de la requête la déclaration `SERVICE` est exécutée. Vous pouvez annuler ce placement à l'aide de l'indicateur de requête [joinOrder](sparql-query-hints-joinOrder.md).

## Contrôle d'accès pour les requêtes fédérées dans Neptune
<a name="sparql-service-auth"></a>

Neptune utilise Gestion des identités et des accès AWS (IAM) pour l'authentification et l'autorisation. Le contrôle d'accès d'une requête fédérée peut impliquer plusieurs instances de base de données Neptune. Ces instances peuvent avoir des exigences différentes pour le contrôle d'accès. Dans certaines circonstances, cela peut limiter votre capacité à effectuer une requête fédérée.

Prenons l'exemple simple présenté dans la section précédente. *Neptune-1* appelle *Neptune-2* avec les mêmes informations d'identification avec lesquelles il a été appelé.
+ Si *Neptune-1* a besoin d'une authentification et d'une autorisation IAM, mais que ce n'est pas le cas pour *Neptune-2*, vous avez simplement besoin des autorisations IAM appropriées pour *Neptune-1* pour pouvoir effectuer la requête fédérée.
+ Si *Neptune-1* et *Neptune-2* ont tous les deux besoin d'une authentification et d'une autorisation IAM, vous devez attacher les autorisations IAM pour que les deux bases de données puissent effectuer la requête fédérée. Les deux clusters doivent également se trouver dans le même AWS compte et dans la même région. Les architectures de requêtes fédérées and/or entre régions et comptes ne sont actuellement pas prises en charge.
+ Toutefois, si IAM n'est pas activé sur *Neptune-1*, mais qu'il l'est pour *Neptune-2*, vous ne pouvez pas effectuer de requête fédérée. Cela s'explique par le fait que *Neptune-1* ne peut pas récupérer vos informations d'identification IAM et les transmettre à *Neptune-2* pour autoriser la deuxième partie de la requête.