Publication scbatch et choix de skin

Bonjour,

J’ai paramétré, sur un serveur 4.2, un fichier build.xml pour lancer la publication d’un module. Il s’agit d’une publi web auroraW pour laquelle je voulais utiliser un skin donné. La publication se fait bien mais avec le skin Aurora par défaut et non le skin que je lui ai indiqué.
Dans le build.xml j’ai, au contenu « réel » près, ceci :

    <scServer url="http://127.0.0.1:8080/scenariserver4.2/s/u/batch" user="XXXXX" password="YYYYY" failProperty="error" haltOnError="false" verbose="true">
        <generate wspCode="MonCodeAtelier" rootItemUri="MonCheminVersRacine.publi" destPath="MonCheminDestination">
            <type code="auroraW">
                <param key="skin" value="Le_codeSkin_DeMonSkin"/>
            </type>
        </generate>
    </scServer>

Pouvez-vous me dire si j’ai oublié un paramètre ?

Merci d’avance
Franck

Bonjour Franck,
La spécification du skin me semble être correcte dans ce que tu as posté.
Pistes :

  • Erreur dans le code du skin ;
  • Le skin n’est pas activé dans ce contexte, ou absent pour ce générateur.

Coté interface, dans le même atelier, pour le même item et pour le même générateur, la sélection de ton skin fonctionne ?

Antoine
Kelis

Bonjour Antoine,
Le skin est bien activé dans l’atelier et fonctionne quand on le lance depuis l’interface de scenariChain quand au code du skin je suis allé sur l’atelier styler puis copier/coller de l’attribut codeSkin du skinset, Donc je ne vois pas où j’aurais pu me trompé.
Bizarre

La particularité éventuelle c’est que je suis sur un modèle dérivé d’Opale mais le code du generator pointé par le skin dans styler est bien auroraW

Bonjour Franck,
Je viens de retester avec succés :

<scServer url="http://localhost:8080/scserver/s/u/batch" user="xxx" password="xxx" haltOnError="no" verbose="true" >
			<sequence haltOnError="false">
				<generate wspCode="Opale" rootItemUri="/_web.publi" destPath="XXXtest">
					<type code="auroraW">
						<param key="skin" value="~OpaleSkinSunrise3-8"/>
					</type>
				</generate>
			</sequence>
		</scServer>

Je pense que ton identifiant de skin n’est pas correct. C’est en fait un identifiant légèrement plus complet que le code que tu vois dans le skinset, intégrant la version. Exemple pour le skinset de code ‹ OpaleSkinSunrise › en version 3.8 : ~OpaleSkinSunrise3-8.

ps : on essaiera de faire apparaitre ce code complet d’une façon ou d’une autre dans le future scStyler5.0. Difficile en effet d’inventer cette syntaxe :slight_smile:

Antoine
Kelis

Bonjour Antoine,
Ok pour l’idée que ça soit le ode qui soit mauvais, mais du coup comment je sais quel est le bon ? on trouve ça dans le skinset qqpart ?

A+
Franck

Bonjour Franck,
Tu dois appliquer la règle suivante pour reconstruire cet identifiant :
SCENARI4.2- :

identifiantComletDuSkin = ~[codeSkinSet][versionMajeureSkinSet]-[versionMediumSkinSet]_[versionMineureSkinSet]

SCENARI5.0+ :

identifiantComletDuSkin = ~[codeSkinSet][versionMajeureSkinSet]-[versionMediumSkinSet]

Exemple :
image
correspond à l’identifiant : ~monSkinPerso1-4

Ok merci pour le retour
J’ai le skin suivant :


En suivant ton exemple, j’ai entré le code ~xristalUnisciel0-2

Et toujours pas de publi avec le bon skin
J’ai tenté sur le même modèle d’utiliser ~xristalUnisciel0-2-1 puisqu’il y a version mineure mais même résultat.

A+
Franck

Tu peux m’envoyer ton skin compilé en mail privé ?

Re Bonjour,

J’ai fini par trouvé le bon format dans le cas de version contenant une version mineure c’est

identifiantComletDuSkin = ~[codeSkinSet][versionMajeureSkinSet]-[versionMediumSkinSet]_[versionMineureSkinset]

Le fait de t’envoyer le skinpack m’a interpellé et ça a payé.

Un grand merci pour le soutien
Franck

Différence SCENARI4.2 et SCENARI5.0 ça :slight_smile:
Je précise celà dans mon message plus haut

Bonjour Franck,

Désolé d’intervenir un peu tard, surtout à contre temps mais il y avait plus simple pour obtenir les informations concernant les skins sur ton serveur et surtout il y a une imprécision voire une erreur dans la réponse de @anp pour SC5.x.

Si on reprend les informations que tu donnais, tu peux interroger en local ton serveur scenari 4.2 de la manière suivante :

  • Soit avec un navigateur, par exemple « elinks » (sudo apt install elinks):
SCS_USER="admin"
SCS_PW="admin"
SCS_URL="localhost:8080/scserver"
elinks http://${SCS_USER}:${SCS_PW}@${SCS_URL}/web/u/skinPack?cdaction=ListPacks
  • soit avec « curl » et une mise en forme par « jq » (sudo apt install curl jq):
SCS_USER="admin"
SCS_PW="admin"
SCS_URL="localhost:8080/scserver"
HTTP_RESPONSE=$(curl -X GET ${SCS_URL}/web/u/skinPack?cdaction=ListPacks -u ${SCS_USER}:${SCS_PW} -sL ) && echo $HTTP_RESPONSE | jq

Dans les deux cas, tu obtiens une réponse de type JSON contenant toutes les informations nécessaires concernant les skins installés sur le serveur Scenari.

Pour Scenari 5.x, tu obtiens une réponse du même type qui te permettrais alors de te rendre compte que le formatage du « versionning » n’a en fait pas vraiment changé mais ça dépend peut-être du modèle documentaire et de la volonté du dev de modifier ce « versionning ».

Cordialement,

XA

PS: En utilisant le bon verbe HTTP et les bonnes URL, tu peux gérer les utilisateurs, les packs, les skins, les ateliers, pour ça il te faut documenter l’API. Dans mon cas j’utilise swagger dans tous mes déploiements pour proposer une interface d’administration indépendante des clients des dev. upstream.

Petite précision :

Tous ces services sont bien des services dits couramment « REST » qui sont documentés dans le code java directement.

Mais pour nous, éditeur de Scenari, ces services ne constituent pas une API, au sens où nous ne nous engageons pas à ce que les entrées/sorties de ces services soient stables dans le temps. Nous considérons ces services comme des mécaniques d’échanges de données internes qui peuvent évoluer à tout moment.

Ce que dans Scenari nous positionnons comme des APIs au sens des interfaces publiques pour lesquelles nous essayons de préserver « au maximum » la compatibilité sont :

  • le modèle SCENARIbuilder,
  • la couche cliente des services batch.

Tout le reste peut bien évidemment être utilisé « en direct » mais nous ne nous engageons à aucune compatibilité ascendante. Nous ne souhaitons donc pas en maintenir une documentation « publique », au delà de celle intégrée au code java (en libre accès), car cela serait contradictoire.

Bonjour Monsieur Spinelli,

Merci d’apporter cette précision pour Frank et tous les professionnels de l’informatique (administrateurs et développeurs) utilisant vos produits mais il me semble qu’il est bien précisé ci-dessus

que c’est à Frank et donc à chacun de créer et de maintenir sa documentation concernant leurs usages professionnels de Scenari.

Après vérification, il me semble que les commandes proposées ci-dessus pour aider Frank sont valides.

Donc ma question est la suivante :

  • votre intervention a t-elle pour objectif d’invalider mon conseil concernant l’usage des commandes proposées à Frank pour utiliser cette API REST ?

Merci de préciser votre démarche, dans l’intérêt de Frank et des autres professionnels qui seraient amenés à rencontrer le même problème.

Cordialement,

XA

Bonjour Xavier, Sylvain,

Merci pour vos réponses et précisions respectives. Je pense que vos deux interventions sont utiles car d’un coté ça donne une méthode pour retrouver l’information et de l’autre ça met en garde sur le fait que ça puisse évoluer dans le temps.

Amicalement
Franck

Ce n’est qu’une précision mentionnant que ce que tu appelles API n’en est pas une pour nous, au sens d’une interface « publique ». Ce sont de simples services REST internes, qui peuvent néanmoins être utilisés, mais nous ne nous engageons pas à les maintenir dans le temps.