Initialisation contexte simplicité

Bonjour,

mon client vient de me demander de faire une évolution sur une application qui a une partie Simplicité et une partie custom.
Le problème c’est que je n’ai jamais suivi de formation Simplicité et que ces connaissances se sont perdues (donc je fais du retro-ingenieering pour comprendre comment faire).

L’évolution a effectuer est plutôt simple mais le problème c’est que le client voudrait que ça reste cohérent avec le reste de l’appli, ce qui fait qu’il va falloir que j’utilises la sur-couche Simplicité pour requêter en base.
Le processus que je veux faire va être sous la forme d’un script shell qui va lançer un excécutable JAVA (jar) qui lui va effectuer les traitements principaux. je dois donc utiliser un objet Grant pour lire la BDD.
Pour faire mes tests, j’ai mis le code suivant: Grant.getAdmin().query(maRequete).
Mais quand j’excecute ça, j’ai des erreurs du type javax.naming.NameNotFoundException: ejbGrantManager not bound;

J’imagines que le contexte Simplicité nécessaire à la connexion avec la base n’est pas bien setté, mais du coup j’aimerais savoir ce qu’il faut faire. Je n’ai aucuns autre exemples du même genre, puisse que le seul script qui lance directement du JAVA appel une classe Simplicité (AdapterImport) que je ne peux pas décompiler.

Je précises que la version Simplicité utilisée dans l’appli est la 2.6.2 (donc plus maintenue).

Cordialement,
Léo

Bonjour,

Afin de mieux cerner votre demande et trouver la personne la plus à même de vous fournir une réponse pertinente et contextualisée, merci de préciser le projet dont on parle. Merci.

Dans les versions 3.0+ ce genre de choses se scripterait très facilement en faisant des appels curl authentifiés:

Dans les versions legacy 2.6.x qui ne sont effectivement plus maintenues à date (cf. https://www.simplicite.io/resources/documentation/versions.md), comme dans la version 2.7.0 qui est elle aussi en toute fin de vie, en fonction du besoin, il est envisageable de passer:

Bref il y a plusieurs approches possibles mais il faudrait idéalement commencer par une formation de base à la plateforme.

PS: en regardant le code de la 2.6.2 MAINTENANCE10 (i.e. la release de maintenance la plus récente de la version 2.6.2) je vois qu’il existait déjà des webservices REST, je pense qu’ils sont un peu différents et sans doute plus basiques que ceux des versions plus récentes mais c’est peut être aussi une approche à envisager au même titre que les webservices SOAP).