SAL : Shared Access Layer - Valiantys - Atlassian Platinum Partner
logo-bleu_rvb.png
Back

SAL : Shared Access Layer

SAL (couche d’accès partagés en français) fournit un ensemble d’API, permettant de réaliser les tâches communes à tous plugins, indépendamment de l’application Atlassian. Quelque soit le plugin que l’on développe, qui ne veut pas persister sa configuration dans l’application ? Avoir des labels internationalisés ?  Ces tâches archi-communes, on parle ici de « services » sont malheureusement gérées différemment pour chaque produit. SAL permet d’unifier tout cela, et de simplifier grandement la vie du développeur. Il est évident que pour des plugins x-produit (qui s’installe aussi bien sur JIRA que sur Confluence par exemple), SAL devient indispensable.

Pour la majorité des plugins (mono-application). Les développeurs ont le choix : utiliser directement l’API du produit ou s’appuyer sur SAL. L’utilisation de SAL quand elle est possible est à privilégier. Pourquoi réécrire sans arrêt les mêmes choses ? Voilà une API qui va évoluer, s’améliorer, nous éviter les pièges de tels ou tels framework utilisés par telles applications, prendre en compte tels spécificités de JIRA ou Confluence. Bref, il n’y a plus à hésiter…

Voici les services les plus communs pris en compte par SAL :

  • La planification des tâches
  • L’internationalisation des labels (utilisé dans les Gadget)
  • La persistance de configuration du plugin.
  • L’upgrade d’un plugin.

Rien ne vaut l’exemple pour illustrer un propos…

La persistance de la configuration d’un plugin :

SLA fournit un objet PluginSettings qui est obtenu depuis l’interface PluginSettingsFactory comme montré ci-après :

PluginSettings pluginSettings = pluginSettingsFactory.createGlobalSettings();

La classe concrète de la fabrique : JiraPluginSettingsFactory ou ConfluencePluginSettingsFactory… sera choisie en fonction du produit en cours d’utilisation (c’est lors de l’injection du component que cela se decidera). Chaque produit va donc gérer ces properties à sa façon, JIRA utilisera le framework propertySet, Confluence s’appuiera lui sur Bandana, mais tout ceci sera restera transparent pour nous. Un même code pour un plugin x-produit permettra de persister la configuration d’une manière ou d’une autre en fonction du produit sur lequel on installe le plugin.

Voici le diagramme des classes associés :

Diagramme des classes SAL
Diagramme des classes SAL

Utilisation des service SAL

Il faut :

1-      Déclarer in component-import dans le atlassian-plugin.xml du plugin...

<component-import
key=”userManager”
interface=”com.atlassian.sal.api.user.UserManager” />

2-      Inclure dans le pom.xml les dependances à  SAL:

<dependency>
<groupId>com.atlassian.sal</groupId>
<artifactId>sal-api</artifactId>
<version>2.0.0</version>
<scope>provided</scope>
</dependency>

Attention à la version en fonction du produit cible, il peut y avoir un impact.

Pour aller plus loin :

http://confluence.atlassian.com/display/SAL/Shared+Access+Layer+Developer+Documentation

http://confluence.atlassian.com/display/SAL/SAL+Version+Matrix

http://confluence.atlassian.com/display/SAL/SAL+Services

Cutted Triangle

Subscribe to the Valiantys Newsletter

Demande enregistrée ! Demande en cours... Ceci n'est pas un email Une erreur s'est produite

In accordance with our privacy policy, we are committed to respecting your personal data.

Contact us

Our Atlassian certified consultants will be happy to answer you.

Join us

We're building the next dream team - Are you in?

Follow us

Nous utilisons des cookies pour le fonctionnement de ce site, pour améliorer son utilisation, personnaliser votre expérience et réaliser des statistiques de visite. Vous pouvez gérer les paramètres et choisir d’accepter ou non certains cookies durant votre navigation. Pour plus d’informations, consultez notre politique de confidentialité. Nos politique de confidentialité

Paramètres de confidentialité

Afin de faciliter votre navigation et de vous apporter le meilleur service possible, nous utilisons des cookies pour améliorer le site aux besoins des visiteurs, notamment selon la fréquentation.  Pour plus d’informations, consultez notre politique de confidentialité. Nos politique de confidentialité

Recaptcha

Google reCAPTCHA est un système conçu pour distinguer les humains des ordinateurs, de telle sorte que les bots soient incapables de remplir les formulaires de manière malveillante au nom d’un être humain.

Analytics

Utilisé pour envoyer des données à Google Analytics sur le périphérique et le comportement du visiteur. Suit l'internaute à travers les appareils et les canaux de marketing. Utilisé par Google Analytics pour diminuer radicalement le taux de requêtes. Enregistre un identifiant unique utilisé pour générer des données statistiques sur la façon dont le visiteur utilise le site.

LinkedIn

Cookies pour une publicité ciblée : Ces cookies peuvent être mis en place au sein de notre site Web par nos partenaires publicitaires. Ils peuvent être utilisés par ces sociétés pour établir un profil de vos intérêts et vous proposer des publicités pertinentes sur d'autres sites Web. Ils ne stockent pas directement des données personnelles, mais sont basés sur l'identification unique de votre navigateur et de votre appareil Internet. Si vous n'autorisez pas ces cookies, votre publicité sera moins ciblée.

Cookies "réseaux sociaux" : Ces cookies sont activés par les services proposés sur les réseaux sociaux que nous avons ajoutés au site Web afin de vous donner la possibilité de partager notre contenu avec votre réseau et vos connaissances. Ils nous permettent également de suivre votre navigation sur d’autres sites Web et d’établir un profil de vos intérêts. Cela peut avoir un impact sur le contenu et les messages affichés sur les autres sites Web que vous consultez. Si vous n'autorisez pas ces cookies, il se peut que vous ne puissiez pas utiliser ou visualiser ces outils de partage.