Discussion :

[fprovot]

Bonjour,
J'ai beau fouiller un peu partout, je n'ai pas trouvé de réponse claire (avec exemple) sur l'utilisation des alias, pour les migration de plateforme (les promotions):
J'utilise oracle, et j'ai un job qui utilise 5 datastores.
J'ai une base de développement, une de test, et une production.
Ma base de test a pour nom de service (ou "connection name") :

• connectionDev

et comme schema (ou "user name") du premier datastore :

• usernameDev

contenant beaucoup de tables.

Pour le test (qui se fait sur une autre plateforme) j'ai

• connectionTest
• usernameTest

et les mêmes tables.

Pour une prod (qui se fait sur une autre plateforme) j'ai

• connectionProd
• usernameProd

et les mêmes tables.

Je précise qu'à un instant je n'ai accès qu'à une seule plateforme depuis dataservice, car aucune n'est liée par réseau. De plus dans les faits j'ai le même libellé de schema entre test et prod : usernameTest = usernameProd.

Il fut un temps où j'ai essayé d'utiliser les alias de datastore, avant d'abandonner car j'avais plein de problèmes. J'aimerai retenter mais en sachant ce que je fais.

1) dois-je mettre le même alias à chaque configuration de datastore?
2) l'alias est-il bien le "username" de la configuration par defaut?
3) ayant des scripts SQL dans mon job, dois-je utiliser la fonction db_owner pour que mes scripts fonctionnent toujours, et avec quels arguments? ( SQL(db_owner(?,?),'requete') )

Peut-être y a-t-il une page web qui décrit tout ça, mais je ne l'ai pas trouvée.

Merci d'avance.

[fprovot]

Voici mes tests, qui ne fonctionnent pas :

Mes deux configurations dans le datastore D1:
DEV :
* DB Connection name : INST1
* User Name : USER1
* Alias USER1 = USER1

TEST :
* DB Connection name : INST1
* User Name : USER2
* Alias USER1 = USER1

(j'ai mis le même alias)

Système configuration:
Datastore D1 : CONFIGDEV = DEV et CONFIGTEST = TEST.

Code d'un script SQL:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
$G_real_owner = db_owner('USER1','USER1');
print( 'G_real_owner  : ' || $G_real_owner  ) ;
 
$G_sys_source = SQL('USER1','SELECT par_libe_param FROM [$G_real_owner].dwp_param WHERE par_code_param = \'G_sys_source\'');
print('Systeme Source : ' || $G_sys_source) ;

Exécution en sélectionnant la configuration CONFIGDEV puis CONFIGTEST.

Dans les deux cas l’exécution se fait sur DEV uniquement:

G_real_owner : USER1
Systeme Source : DEV
(et non USER2 et TEST pour le second)

Je ne comprend pas pourquoi ça ne marche pas, la configuration semble ne pas être prise en compte.
Sont-ce mes alias qui ne sont pas bien définis?

[fprovot]

Bon ça y'est, mon test de base marche!
La doc et les blogs étaient clairs comme de l'eau de roche, mais la bonne méthode est elle bien logique:

Nom de l'alias : un nom générique qu'on utilise partout.
Alias d'une configuration: le nom du user de cette configuration (ce qui duplique le champ "user name" sans que j'en comprenne la raison)
Exemple:
Datastore D1: 2 configurations.
ConfigDEV : Alias ALIASD1 = USER1
ConfigTEST : Alias ALIASD1 = USER2

code : $G_real_owner = db_owner('D1','ALIASD1');

et là j'obtiens bien,
avec ConfigDEV
G_real_owner : USER1
Systeme Source : DEV

avec ConfigTEST
G_real_owner : USE21
Systeme Source : TEST

Reste à voir si ça marche aussi pour des connexions différentes...

[EDIT]
En effet, il semble bien que si les deux configurations sont sur des connexions différentes (SID d'oracle), ça marche aussi!

[fprovot]

Après de nombreux tests, je me suis aperçu que les alias me sont inutiles. En effet la simple utilisation des configuration sans s'occuper de gestion d'alias fait la même chose. Donc la recherche et l'utilisation du db_owner ne sert à rien.

D'où ma question : quel peut être un cas précis ou l'utilisation des alias de datastores est nécessaire?

Merci

[fprovot]

Précision utile et réponse à la question précédente: Tout marchait bien avec ou sans alias de datastore en script! Mais certains dataflows utilisaient la mauvaise base de données. Après pas mal de tests, j'ai fini par comprendre que

• quand on utilise des tables en mode objet graphique, les alias sont nécessaires.
• le nom de l'alias DOIT être le nom du user avec lequel les tables ont été importées dans le projet. (alors qu'en script sql n'importe quel nom marche)
• les valeurs des alias doivent bien être les noms des users substituants celui par defaut lors du run-time.

Donc si on a un datastore D1, avec une table T1(D1,User1),
alors l'alias de datastore doit s'appeler User1, et sa valeur pour la première configuration sera User1, puis User2 pour la seconde, etc...).

J'espère que ça servira à d'autres.

[cedrickb]

Pour répondre à la question:

quel peut être un cas précis ou l'utilisation des alias de datastores est nécessaire?

=> Ca dépend
je sais c'est une réponse de normand!
En fait ça dépend vraiment du contexte de déploiement de la solution data services.
Généralement l'utilisation des alias permet de simplifier l'exécution des flux d'alimentation dans un environnement spécifique dans le cadre de déploiement avec plusieurs développeurs. Ca simplifie le processus de migration également...

Il n'existe pas de réponse pré définie telle que "dant tel cas il faut utiliser les alias", c'est à envisager au moment de la définition de l'architecture technique DS en fonction des besoin de la structure.

++

[cedrickb]

le nom de l'alias DOIT être le nom du user avec lequel les tables ont été importées dans le projet. (alors qu'en script sql n'importe quel nom marche)

=> pas tout à fait. Le nom de l'alias défini au niveau du datastore ne détermine pas sa valeur.
En fait tu peux créer un alias dans ton datastore qui portera le nom MONALIAS et dans la configuration, utiliser pour ton environnement 1 la valeur USER1 pour l'alias portant le nom MONALIAS, et pour ton environnement 2 la valeur USER2.