Application install from git repo

Oui je pense que le blocage est du à un problème d’accès à la base.
Là je ne peux plus finir mes tests car j’ai perdu la connexion à la VM …
Ticket créé côté TDF…

Bonsoir

Nous allons pousser ce soir ou demain une révision 5.2.26 de la plateforme qui devrait régler le pb d’importspec dans le cas qui nous intéresse ici (ainsi que les messages d’erreur parasites liés à la réindexation forcée au post import module).

Je te tiendrai au courant quand les images de cette révision seront disponibles.

La révision 5.2.26 a été poussée ce matin et les images buildées et mises à dispo sur le (image registry.simplicite.io/platform:5-latest.

Il faut impérativement puller cette image à jour, et supprimer la précédente (5.2.25).

Je viens de tester un démarrage from scratch avec les modules en import spec (avec des URIs Git sur Github en SSH), ça c’est bien passé, le résultat semble OK (et aucun message d’erreur parasite).

Voilà mon docker compose:

version: "3"
services:
  database:
    image: postgres:latest
    environment:
      POSTGRES_USER: "simplicite"
      POSTGRES_PASSWORD: "simplicite"
      POSTGRES_DB: "simplicite"
    volumes:
      - data:/var/lib/postgresql/data
    network_mode: bridge
  simplicite:
    image: registry.simplicite.io/platform:5-latest
    environment:
      DB_SETUP: "true"
      DB_VENDOR: "postgresql"
      DB_HOST: database
      DB_USER: "simplicite"
      DB_PASSWORD: "simplicite"
      DB_NAME: "simplicite"
      DB_WAIT: 100
      SSH_KNOWN_HOSTS: "github.com"
      DOCKER_HOST_IP: ${DOCKER_HOST_IP}
      MODULES_IMPORT_SPEC: |
        title: "Vision 360° TDF"
        modules:
          - name: "TdfInfra"
            version: "0.9"
            git:
              uri: "git@github.com:simplicitesoftware-projects/module-tdfinfra.git"
          - name: "TdfInfraFrontend"
            version: "0.9"
            git:
              uri: "git@github.com:simplicitesoftware-projects/module-tdfinfra-frontend.git"
          - name: "TdfInfraHELIOS"
            version: "0.9"
            git:
              uri: "git@github.com:simplicitesoftware-projects/module-tdfinfra-helios.git"
          - name: "TdfInfraREFACCES"
            version: "0.9"
            git:
              uri: "git@github.com:simplicitesoftware-projects/module-tdfinfra-refacces.git"
          - name: "TdfInfraAnomalies"
            version: "0.9"
            git:
              uri: "git@github.com:simplicitesoftware-projects/module-tdfinfra-anomalies.git"
    ports:
      - 127.0.0.1:8443:8443
    volumes:
      - ./.ssh/id_ed25519:/usr/local/tomcat/.ssh/id_ed25519:ro
      - ./context.xml:/usr/local/tomcat/webapps/ROOT/META-INF/context.xml
      - git:/usr/local/tomcat/webapps/ROOT/WEB-INF/git
    extra_hosts:
      - "dockerhost:${DOCKER_HOST_IP}"
    network_mode: bridge
    links:
      - database:database
    depends_on:
      - database
volumes:
  data:
  git:

NB: Dans mon cas c’est le host Docker qui héberge le serveur Oracle des bases HELIOS et REFACCES, d’où certaines configs spécifiques à ce cas précis

J’ai mis à jour la documentation d’installation: Vision 360° TDF - Installation, c’est à cette doc qu’il faut se référer.

Bonnes nouvelles (c’est noël)
J’ai testé l’import_spec avec succès (en mode https)
La connexion avec la base HELIOS fonctionne bien chez TDF (avec un FROM qui inclue un préfix, je ne sais pas si c’est prévu dans vos dèv)

image

Pour refaccess c’est ko mais c’est normal …

Bonnes fêtes de fin d’année

Ok super

Il faudra juste ajouter le schéma dans le nom de table des objets Helios. Ex: HELIOS;Q_HELIOS_PUBLICATION.SIO_SITE

Bonne fête

Bonjour David,

Meilleurs voeux,
Pour info la connexion refacces fonctionne sur la machine tdf d’intégration.
Exemple de requête sur le schéma ACCES_SITE (celui que vous utilisez a priori)
SELECT count(*) from ACCES_SITE.IG;

Bonne journée
Stéphane

Par contre la recherche semble ne pas fonctionner sur l’instance installée chez tdf
Exemple par code postal
Est-ce du au préfix ACCES_SITE qui n’est pas pris en compte dans les dèvs actuels ?

image

Stéphane

Bonjour et bonne année

Mes bases Oracle de test (HELIOS et REFACCES) sont chargées sur le schema par defaut du user qui se connecte donc le paramétrage de DEV ne précise pas de schema.

Je vais voir s’il est possible de recharger les bases Oracle de test sur un schéma avec un nommage iso-cible.

En attendant il faut ajouter manuellement ce nom de schema sur les objets métier qui pointent sur les tables HELIOS et REFACCES

Sinon pour ce qui est du test via le frontend, ça ne tape pas dans les tables/vues HELIOS et REFACCES, mais dans les tables “mirroir” dans la base de données par défaut.

Ces tables mirroir (en fait je devrais plutôt dire ces tables renormalisées car c’est de cela qu’il s’agit) sont alimentées, de manière sélective et en delta, par les adapter ad hoc.

D’où la nécessité de jouer les procédures d’ “import HELIOS” et “import REFACCES” tel que documentées dans le doc d’install: Vision 360° TDF - Installation

En prérequis à ces imports il faut bien entendu que la tuyauterie vers ces tables/vues fonctionne. Pour mémoire, ces tables/vues sot mappés sur des objets métier accessibles sur la UI backend:

Ex: la vue SIO_SITE d’HELIOS:

De toute manière pour tester il faut toujours commencer par vérifier que tout est OK au niveau de la UI backend avent d’envisager d’aller voir si c’est accessible coté frontend, le frontend c’est la “cerise sur le gâteau”…

  1. Peux tu confirmer que le nom de schema Oracle HELIOS de prod est bien Q_HELIOS_PUBLICATION et que celui de REFACCES est bien ACCES_SITE ?

  2. Peux tu aussi confirmer que les users qui se connectent à ces bases Oracle ont bien un autre nom que ces noms de schema ? Je pose la question car si on utilise le user du schema, alors le prefixage explicite avec le nom de schema est inutile (comme sur mes bases Oracle de test)

J’ai vu la procédure pour modifier mes bases de dev, c’est un peu pénible donc si je peux éviter de le faire plusieurs fois ça m’arrange.

Je te confirme tes deux points

OK je vais faire la manip sur mes bases de test, le paramétrage pourra ensuite être modifié pour mettre un nom de schema explicite, à la prochaine livraison il n’y aura plus rien à modifier.

En attendant voici, à priori, le XML à importer pour faire les modifs qui vont bien (via la UI backend > les raccourcis (icône en haut à droite) > Import XML) :

<?xml version="1.0" encoding="UTF-8"?>
<simplicite xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.simplicite.fr/base" xsi:schemaLocation="http://www.simplicite.fr/base https://www.simplicite.io/resources/schemas/base.xsd">
<object>
	<name>ObjectInternal</name>
	<action>update</action>
	<data>
		<obo_name>TdfEquipementHELIOS</obo_name>
		<obo_dbtable>HELIOS;Q_HELIOS_PUBLICATION.SIO_EQUIPEMENT</obo_dbtable>
	</data>
	<data>
		<obo_name>TdfInfraHELIOS</obo_name>
		<obo_dbtable>HELIOS;Q_HELIOS_PUBLICATION.SIO_INFRA</obo_dbtable>
	</data>
	<data>
		<obo_name>TdfServiceClientHELIOS</obo_name>
		<obo_dbtable>HELIOS;Q_HELIOS_PUBLICATION.SIO_SERVICEC</obo_dbtable>
	</data>
	<data>
		<obo_name>TdfSiteHELIOS</obo_name>
		<obo_dbtable>HELIOS;Q_HELIOS_PUBLICATION.SIO_SITE</obo_dbtable>
	</data>
	<data>
		<obo_name>TdfConsigneSecuriteREFACCES</obo_name>
		<obo_dbtable>REFACCES;ACCES_SITE.CONSIGNE_SECU</obo_dbtable>
	</data>
	<data>
		<obo_name>TdfSiteConsigneSecuriteREFACCES</obo_name>
		<obo_dbtable>REFACCES;ACCES_SITE.IG_CONSIGNE_SECU</obo_dbtable>
	</data>
	<data>
		<obo_name>TdfSiteREFACCES</obo_name>
		<obo_dbtable>REFACCES;ACCES_SITE.IG</obo_dbtable>
	</data>
</object>
</simplicite>

J’ai fait la manip sur mes bases Oracle de test.

J’ai ajouté les préfixes avec les noms de schema qui vont bien pour les objets qui pointent sur les tables/vues de ces bases, ex:

Lors de la prochaine livraison chez TDF des modules à jour il n’y aura donc plus à modifier le paramétrage.

Bonjour David,

J’ai fait la manip de modification des tables à la main dans les objets métier.
Outre le fait qu’il me lance une erreur d’alter

exemple : Erreur SQL requête: ALTER TABLE SIO_INFRA RENAME TO Q_HELIOS_PUBLICATION.SIO_INFRA

a priori la valeur est bien positionnée.

J’ai ensuite lancé l’import helios et il semble que les requêtes générées ne soient pas correctes
Exemple

select … from Q_HELIOS_PUBLICATION.SIO_INFRA t left outer join SIO_SITE t_tdfHeliosLocCodeIG …

Le FROM est correct mais le OUTER JOIN non, il manque le préfix pourtant bien pris en compte dans la conf.

Il faut ajouter le prefix sur toutes les tables externes HELIOS/REFACCES => le plus simple est d’importer le XML que j’ai mis plus haut.

Les erreurs d’alter table peuvent être ignorées c’est plus des warnings que des erreurs.

Oui c’est bien ce que j’ai fait “à la main” sur toutes les tables

L’import via XML n’a pas fonctionné (tourne dans le vide mais sans log particulier dans la console)
Un fois relancé le serveur seul le premier objet (TdfEquipementHELIOS) était modifié.
Je pense qu’il y a la même erreur que lorsque je le fais à la main ( ALTER TABLE … ) et que ça bloque la modification des autres objets.

Exemple, la conf de la table SIO_SITE est correcte pourtant dans le JOIN je n’ai pas le prefix

Je vais essayer le vidage de cache

Je ne suis pas sûr de comprendre le pb. Un clear cache ne fait jamais de mal

Sur mon instance de test, pour vérifier les requêtes SQL, j’ai temporairement activé la trace des requêtes SQL (param systeme LOG_SQL_USER à yes) et j’ai bien les prefixes dans les joins:

ATTENTION: ne jamais laisser LOG_SQL_USER à yes plus que nécessaire pour regarder un pb car c’est extremement verbeux et ça impacte très notablement les perfs

Ok ça semble bon cache vidé, il faut que je prenne le réflexe de la faire plus souvent

De manière générale, un clear cache global (bouton rouge) est toujours la première à tenter en cas de comportement “bizarre/inattendu”.

C’est quasi impératif quand on modifie du paramétrage “sensible”, typiquement quand ça touche les droits (Simplicité fait des clear cache partiels mais il y a des cas où c’est pas possible / pas exhaustif).

Là les changements de noms de tables n’auraient pas du poser pb mais j’avoue ne pas bien savoir exactement ce qui se passe dans le cas particulier d’un nom de table sur datasource externe avec un préfix de schema, c’est un cas “rare”…

Pour ce qui est des imports HELIOS et REFACCES avant de lancer l’import complet qui prendra certainement du temps la 1ère fois (après ça fonctionne normalement en delta), il faudrait d’abord tester sur un site unitaire:

  1. via le formulaire d’un site HELIOS:

  1. via le formulaire d’un site REFACCES:

Pour rappel on peut consulter les infos relatives à un chargement de fichier via la supervision des imports, ex:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.