Introduction
En utilisant CIS (Component Integration Services), il est possible :
- d’accéder à des tables dans des serveurs distants comme si ces tables étaient locales.
- de réaliser des jointures entre des tables appartenant à des serveurs distants hétérogènes (Oracle, ASE…).
- de transférer le contenu d’une table dans une autre table appartenant à un autre serveur distant supporté avec la commande
select into
. - de maintenir l’intégrité référentielle au sein de sources de données hétérogènes.
Afin que CIS fonctionne, deux étapes sont nécessaires :
- l’installation des serveurs DirectConnect (tels que ASE, ASIQ, ASA, etc.) ou les passerelles pour les sources de données externes auxquelles on désire accéder (Oracle, DB2, Informix).
- la configuration du serveur pour accéder aux objets distants.
La présente fiche technique propose d’exposer les deux aspects les plus importants de la mise en œuvre de CIS :
- l’ajout de serveurs distants
- comment effectuer la correspondance dans le serveur local avec les objets distants
Ajout d’un serveur distant
Dans le fichier interfaces ($SYBASE
) l’entrée pour le serveur distant en question doit être spécifiée.
Dans le serveur local, les entrées pour le serveur distant dans la table système sysservers
doivent être ajoutées. sp_addserver
est destinée à cette manipulation.
execute sp_addserver server_name [,server_class [,network_name]]
server_name |
Nom logique utilisé pour identifier le serveur. Celui-ci doit être unique. |
server_class |
Type du serveur. |
network_name |
Nom du serveur dans le fichier interfaces. |
Exemple :
execute sp_addserver "DS2", ASEnterprise, "DS2"
Les types de serveur disponibles sont regroupés ci-dessous :
- ASEnterprise ( >= v 11.5)
- ASAnywhere ( >= v 6.0)
- ASIQ ( >= v 12.0)
- sql_server ( <= v 4.9)
- db2
- direct_connect
Test de la connexion
Pour tester la connexion au serveur distant :
connect to DS2
go
La connexion demeurera active tant que la commande disconnect ne sera pas appelée.
En cas de problèmes de connexion, le problème peut éventuellement être résolu en s’assurant que le paramètre "enable cis
" a pour valeur 1 (sp_configure 'enable cis'
). Le paramètre 'enable cis
' est statique (le serveur doit être redémarré).
Il se peut également que la connexion échoue à la suite d’un login incorrecte, dans ce cas ne pas oublier la procédure sp_addexternlogin
.
Syntaxe :
execute sp_addexternlogin remote_server, login_name,
remote_login_name [,remote_login_password]
Correspondance entre les objets distants et les tables proxy locales
Pour effectuer la correspondance entre un objet distant et une table proxy locale, cette opération se déroule en deux étapes :
- appel de la procédure
sp_addobjectdef
pour définir la location physique de l’objet distant - utilisation de la commande
create table
oucreate existing table
pour créer la table proxy locale.
Localisation physique de l’objet distant
Syntaxe :
execute sp_addobjectdef tablename, "objectdef" [,"objecttype"]
tablename |
Nom de l’objet défini comme une table locale. Ce paramètre peut être
donné sous différentes formes
|
objectdef |
Chaîne de caractères indiquant la localisation physique externe de
l’objet externe. Cette chaîne de caractères a la format server_name.db_name.owner.object .
server_name et object sont obligatoires. |
objecttype |
Type de l’objet qui peut être une table, une vue ou le jeu de résultats (result set)
d’une procédure RPC (remote procedure call) : trois types possibles comme cela a
été mentionné pour la paramètre objectdef
|
Exemple :
execute sp_addobjectdef "T_REMOTE","DS2.db_work.dbo.T_REMOTE","table"
L’appel de la procédure sp_addobjectdef
doit être réalisé impérativement avant le lancement des commandes create table
ou create existing table
.
(Voir sp_dropobjectdef
pour la suppression de définitions d’objets distants).
La procédure système sp_addobjectdef
écrit des données dans la table système sysattributes
.
La requête ci-après permet de repérer rapidement les objets définis :
select object_cinfo
from sysattributes
where object_type="OD"
La procédure système sp_dropobjectdef
permet de supprimer ces définitions d’objets.
Création d’une table locale proxy reposant sur une table distante
Pour créer une table locale proxy lorsque la table distante est existante, la commande create existing table
est utilisée.
Syntaxe :
create existing table(...)
[external table | procedure]
at "server_name.database_name.owner.object_name"
Exemple :
create existing table T_LOCAL (id integer not null) at "DS2.db_work.dbo.T_REMOTE"
Il est également possible de créer la table proxy locale lorsque la table distante est existante en utilisant la commande create proxy_table
. Avec cette commande, toutes les colonnes présentes dans la table distante sont dérivées dans la table proxy locale.
Syntaxe :
create proxy_table nom_table
[external table]
at "server_name.database_name.owner.table_name"
Par défaut la commande proxy_table
comprend external table
, qu’il s’agisse d’une table distante ou d’une vue distante. Exemple :
create proxy_table T_CIS3 at "DS2.db_work.dbo.T_CIS_REMOTE"
Pour créer la table locale proxy et la table distante, la commande classique create table
est utilisée
Syntaxe :
create table table_name (...)
[external table]
at "server_name.database_name.owner.table_name"
Exemple :
create table T_CS1_LOCAL (id integer not null) at "DS2.db_work.dbo.T_CS1_REMOTE"
Création d’une table locale proxy reposant sur le resultset d’une procédure stockée distante
Le resultset d’une procédure stockée peut être implémenté grâce à CIS dans une table proxy locale. La table proxy doit refléter le resultset de la procédure stockée distante appelée.
Syntaxe :
create existing table (...)
external procedure
at "server_name.database_name.owner.procedure_name"
Les syntaxes create table
et create proxy_table
sont interdites lorsqu’il s’agit d’une procédure stockée distante.
Exemple :
create existing table T_RPC_REMOTE
(
id integer not null,
libelle varchar(20),
libelle2 varchar(20)
)
external procedure at "DS2.db_work.dbo.ps_rpc"