La checklist du développeur Qlik Sense : script, modèle, nommage, sécurité

Pourquoi une checklist

Le document d’origine portait une consigne en en-tête : « à imprimer et plastifier ». Les défauts qui coûtent le plus cher en production sont rarement des problèmes d’expertise : ce sont des oublis. Une clé synthétique passée inaperçue, un champ technique conservé « au cas où », une Section Access en minuscules. Une liste courte, cochée à chaque livraison, les attrape avant l’utilisateur.

La checklist en un coup d’œil, par famille de contrôles.

Script : un code qu’on peut reprendre

• La première section du script est une section d’information : objet de l’application, sources, historique des modifications.
• Chaque domaine fonctionnel (ventes, clients, calendrier…) a sa propre section dans l’éditeur de chargement de données ; les sections jouent le rôle des onglets de QlikView.
• Chaque bloc de code est précédé d’un commentaire, et chaque modification est datée.
• Toutes les sources passent par des connexions de données (lib://…). Elles remplacent les chemins UNC et les chaînes ODBC que l’on isolait dans des fichiers include ou dans le script caché de QlikView, qui n’existe pas dans Qlik Sense.
• Le journal de rechargement est disponible et consulté : c’est l’équivalent de l’option « Generate Logfile » de QlikView.
• Les drapeaux sont numériques (1/0) dès que possible.

Modèle de données

• Aucune clé synthétique ni référence circulaire (les « boucles » de QlikView) : la visionneuse du modèle de données les signale.
• La granularité est la bonne : le grain de chaque table correspond aux analyses attendues.
• Les QVD sont utilisés partout où c’est possible, et leurs lectures restent optimisées.
• Les tables se joignent sur des entiers ; les grandes clés concaténées sont remplacées par AutoNumber().
• Les clés système et horodatages techniques sont retirés du modèle ; un horodatage utile est découpé en date et heure.
• Les champs inutilisés sont supprimés.
• Les champs de dimension concaténés sont éclatés en champs distincts.
• Les tables en flocon superflues sont fusionnées ; sur les très gros modèles, on se passe de table de liens.

// Optimized QVD read: no transformation here
Orders_tmp:
LOAD * FROM [lib://Sales_QVD/Orders.qvd] (qvd);

Orders:
LOAD
    AutoNumber(Company & '_' & OrderNbr, 'Order')  as %OrderKey,
    CustNo                                         as "Customer Nbr",
    Date(Floor(OrderTimestamp))                    as "Order Date",
    Time(Frac(OrderTimestamp))                     as "Order Time",
    If(InYearToDate(OrderTimestamp, Today(), 0), 1, 0) as _YTDFlag,
    Amount
RESIDENT Orders_tmp;

DROP TABLE Orders_tmp;

Nommage

Les conventions d’origine s’appliquent telles quelles : un préfixe suffit pour savoir à quoi l’on a affaire.

Les préfixes de la checklist, inchangés depuis QlikView.

• Les conventions couvrent les tables, les champs et les variables.
• Variables préfixées v, champs clés %, drapeaux _, tables et champs temporaires suffixés _tmp.
• Les composantes d’une clé composée sont séparées par _.
• Les préfixes < (groupe cyclique) et > (groupe hiérarchique) s’appliquent, dans Qlik Sense, au nom des dimensions principales cycliques et hiérarchiques.
• Les champs portent des noms métier : Customer Nbr plutôt que CustNo.
• Le renommage se fait dans le script, pas dans chaque graphique.

Sécurité : la Section Access

• Le script de sécurité vit dans un fichier include, appelé par $(Must_Include=…), qui fait échouer le rechargement si le fichier manque.
• Upper() est appliqué aux champs de la Section Access et aux valeurs de réduction côté données : Qlik Sense compare en majuscules.
• Le compte de service du rechargement figure en ADMIN : en Client-Managed, INTERNAL\SA_SCHEDULER remplace le compte du service Publisher.

// section_access.qvs, called from the main script with:
// $(Must_Include=lib://Security/section_access.qvs);
Section Access;
Access:
LOAD * INLINE [
ACCESS, USERID, REGION
ADMIN, INTERNAL\SA_SCHEDULER, *
];
Concatenate (Access)
LOAD
    'USER'         as ACCESS,
    Upper(UserId)  as USERID,
    Upper(Region)  as REGION
FROM [lib://Security/users.qvd] (qvd);
Section Application;

Côté données, le champ de réduction est chargé de la même façon : Upper(Region) as REGION.

Performance de l’interface

• Peu de Count(distinct …), peu de If imbriqués, peu de comparaisons de chaînes.
• Analyse d’ensembles (set analysis) contenue sur les grosses tables de faits ; Aggr() évité quand c’est possible.
• Pas de If dans les dimensions calculées.
• Pas de fonctions temporelles comme InMonth() dans les expressions : un drapeau calculé dans le script fait le même travail.
• Peu de visualisations par feuille, et peu de tableaux croisés dans les très grosses applications.
• Une condition de calcul sur les graphiques volumineux.
• Les expressions communes sont centralisées : dans Qlik Sense, les mesures et dimensions principales prennent souvent le relais des variables d’expressions.

Design et livraison

• La couleur sert au contraste et à la mise en avant ; le reste est neutre et sourd.
• Un thème personnalisé porte la charte, et la mise en forme est cohérente entre feuilles et entre objets.
• Les sélections les plus utilisées sont en haut, les moins utilisées en bas.
• L’affichage est adapté aux résolutions des utilisateurs et testé sur leurs terminaux (navigateurs, mobile).
• En Client-Managed, la version de développement est celle de la production. En SaaS, la question ne se pose pas.

Optimiser une application existante

La checklist d’origine se terminait par une méthode de réglage, toujours valable :

1. Réduire les lignes : ne garder que la profondeur d’historique réellement utile.
2. Réduire les colonnes : repérer les champs inutilisés, puis les retirer par des DROP FIELD placés dans la toute dernière section du script. Le DocumentAnalyzer de QlikView a un pendant communautaire, Qlik Sense Document Analyzer ; en Qlik Cloud, l’application de supervision App Analyzer apporte des informations comparables.
3. Réduire le nombre de valeurs distinctes : horodatages et clés système en tête. La visionneuse du modèle de données affiche ce nombre pour chaque champ.
4. Convertir en numérique les champs comparés dans les expressions, comme If(ClientType = 'Direct', …).
5. Simplifier le modèle : fusionner les flocons pour tendre vers une étoile.
6. Simplifier l’application : moins de feuilles, moins d’objets par feuille.
7. Repasser la checklist complète.

Ce qui ne s’applique plus

Les macros n’existent pas dans Qlik Sense, pas plus que le script caché ni l’option « Show Frequency » des listes de QlikView. Le QlikView Optimizer cède la place aux outils cités plus haut. Les colonnes de tableau sont filtrables nativement, ce qui rend inutile la consigne sur les listes déroulantes. Publisher disparaît, et ses abréviations (APR, JOB, SDF, TSK, DSR) avec lui : les rechargements sont des tâches de la QMC en Client-Managed et des rechargements planifiés en SaaS. Seuls les préfixes d’environnement DEV, TST et PRD gardent leur intérêt, transposés au nom des flux, espaces et tâches.

À retenir

• Un modèle propre d’abord. Pas de clé synthétique, pas de boucle, pas de champ inutile : tout le reste en dépend.
• Un script qui se lit. Section d’information, une section par domaine, des commentaires datés.
• Des noms qui parlent. Préfixes v, %, _, suffixe _tmp, noms métier posés dans le script.
• La sécurité dans un seul fichier. Include obligatoire, Upper() partout, compte de service en ADMIN.
• La performance se prépare dans le script. Drapeaux numériques, clés entières, moins de valeurs distinctes.

Source

QV Developer Checklist, checklist de développement QlikView (2017), document interne inspiré des pratiques de la communauté Qlik ; mise à jour Qlik Sense : HeyData.