Bonnes pratiques AppCreator

Choix du plan adapté

Avant de commencer à créer une application dans AppCreator, il importe de comprendre ce qu’offre la plateforme AppCreator et les détails de chaque plan.
Le principe est qu’il vaut mieux disposer d’une capacité au moins 5 à 10 % supérieure au besoin. On veille ainsi à ce que l’application puisse monter en charge en cas de pic d’activité des utilisateurs.
Identifiez qui va utiliser l’application et concevez-la selon les spécifications. Par exemple, vous pouvez choisir un plan de portail client pour répondre aux besoins de vos clients, fournisseurs et partenaires.

Bonnes pratiques de sécurité

Utilisateurs et autorisations

N’ajoutez à l’application que les utilisateurs nécessaires et ne partagez que les modules requis.
Supprimez les utilisateurs ou les développeurs qui n’ont plus besoin d’accéder à l’application.
Si plusieurs utilisateurs créent l’application, ajoutez-les comme développeurs au lieu de partager les identifiants d’administrateur.
N’accordez l’accès aux informations d’identification personnelle (PII) et aux données numériques personnelles relatives à la santé (ePHI) qu’aux jeux d’autorisations nécessaires.
Limitez les autorisations exporter, supprimer, afficher tout et modifier en bloc.
Vous pouvez supprimer les jeux d’autorisations inutiles aux utilisateurs et clients.

Rapports et formulaires

Il faut chiffrer les champs collectant ou contenant des données PII ou ePHI.
On peut masquer les données sensibles dans les rapports, le cas échéant.
On peut ajouter des filtres et des critères aux rapports pour veiller à n’afficher que les données nécessaires aux utilisateurs.
On peut supprimer les données sensibles stockées lorsqu’elles deviennent inutiles.
On peut associer des messages de confirmation à des boutons d’action personnalisés.
Il est déconseillé de collecter ou stocker des données sensibles comme les numéros de sécurité sociale ou les mots de passe. En cas de collecte, il faut indiquer clairement l’objet dans le formulaire.
On conseille d’éviter de stocker des identifiants API dans l’application.
On peut associer un texte ou des bulles d’aide à des champs pour préciser la raison de la collecte des données.
Des champs de note ajoutés à un formulaire permettent d’indiquer aux utilisateurs l’objet de la collecte.
On conseille de désactiver les formulaires publiés une fois l’accès public devenu inutile.
Une case de choix peut servir à obtenir un consentement à la collecte de données.
Il faut utiliser l’authentification OAuth autant que possible pour l’appel d’API.
En cas de collecte d’adresses IP, on conseille d’en informer les utilisateurs et d’obtenir leur consentement. On peut aussi chiffrer les adresses IP.
Il faut examiner les actions de rapport, comme l’ajout, la suppression et la duplication, et les retirer si inutiles.
La fonction de piste d’audit permet aussi de suivre l’historique des modifications apportées aux enregistrements.

Workflows et scripts

Il faut effectuer des validations d’entrée pour les champs autant que possible.
Chaque lien hypertexte utilisé dans l’application doit être vérifié.
Il faut examiner le contenu des tâches de communication (SMS et courriel).
On peut exécuter la logique métier, comme les fonctions et les workflows de calendrier, dans le générateur de workflow lui-même avant l’intégration au flux principal.

Bonnes pratiques d’application

Pratiques générales

Définissez la structure applicative, identifiez le modèle de données (champs, relations, chiffrement de champs) et considérez les problèmes du processus actuel avant de commencer à créer l’application.
Documentez la structure applicative. Cela facilitera les modifications ultérieures.
Attribuez des noms explicites à tous les éléments (formulaires, champs, rapports, workflows, pages, variables, fonctions et jeux d’autorisations).
Utilisez des champs de recherche pour créer des relations entre les formulaires afin d’éviter la redondance de données.
Définissez des propriétés de champ comme obligatoire et aucune valeur en double pour veiller à l’intégrité des données.
Supprimez les éléments inutiles de l’application.
Indiquez le comportement de suppression des enregistrements (effets de la suppression d’un enregistrement donné sur ceux connexes). Par exemple, si on supprime un employé, qu’advient-il des tâches qui lui sont affectées ?
Apportez des modifications à l’application dans un environnement sandbox et testez-les avant de les publier.
Utilisez la fonction de sauvegarde planifiée pour créer des sauvegardes régulières.

Bonnes pratiques Deluge

Deluge est le langage de script intégré à AppCreator. Facile à apprendre, il offre un environnement de développement intégré qui permet de faire glisser et déposer des snippets Deluge pour créer du code.

Pratiques générales

On peut utiliser des instructions de débogage comme info au besoin pour éliminer les erreurs.
Évitez une forte imbrication de scripts et optimisez les boucles.
Utilisez efficacement la tâche d’agrégation d’enregistrements. N’extrayez tous les enregistrements que si nécessaire.
Utilisez les fonctions intégrées autant que possible, car elles offrent une performance optimale.
Les instructions try-catch permettent de traiter des exceptions dans le code.
On peut attribuer des noms explicites aux variables.
Utilisez des variables système comme zoho.appUri et zoho.appName afin que les changements de nom du lien d’application, ou du propriétaire, n’affectent pas la fonctionnalité.
C’est surtout utile pour un script Deluge servant à incorporer des éléments à des pages HTML.
Les fonctions permettent de créer des blocs réutilisables de code souvent utilisé ou dupliqué.
On peut supprimer le code indésirable et commenté pour tenir la base propre, facilitant la mise à jour.
On peut mettre en retrait les scripts et y ajouter des commentaires pour donner un bref aperçu de la logique et l’objet.
Conservez le code modulaire.
Syntax Assist permet de configurer des tâches.
On dispose aussi du contrôle de version pour suivre les diverses versions et modifications de code.
Lorsqu’on utilise la tâche Deluge invokeURL pour passer un appel API, la réponse n’est pas enregistrée ou traitée dans les données qu’AppCreator conserve, préservant Deluge des vulnérabilités.
Une erreur de script Deluge n’affecte que la logique applicative et n’entraîne aucune vulnérabilité.
Les erreurs de syntaxe survenant dans Deluge s’affichent lorsqu’on tente d’enregistrer le script. Le code n’est pas enregistré ou exécuté tant qu’on ne corrige pas l’erreur.
Il faut suivre et corriger les erreurs de logique résultant de mauvaises pratiques de programmation et d’erreurs.
On doit optimiser le code Deluge écrit pour veiller à ne pas atteindre les limites d’instruction. Elles visent à éviter un usage inapproprié accidentel de ressources.
Pour gagner en performance, utilisez les fonctions Deluge prédéfinies : equalsIgnoreCase, equals for comparison rather than "==".

Scripts à éviter

Voici quelques scripts à éviter. Des alternatives sont fournies.

Exemple 1:

Au lieu de vérifier le compteur de l’instruction fetch, on peut utiliser directement la collection fetch dans la boucle.

fetchInvoices = Invoice[Client == input.Client && Location.equalsIgnoreCase("Chennai") && Bill_Payment_Status == "Not Paid"];
if(fetchInvoices.count() > 0)
{
for each invoice in fetchInvoices
{

}
}
//------------------------------------------
//Utilisez plutôt le script suivant
//------------------------------------------
for each invoice in Invoice[Client == input.Client && Location.equalsIgnoreCase("Chennai") && Bill_Payment_Status == "Not Paid"]{

}

Exemple 2:

On peut utiliser des fonctions intégrées pour éviter une boucle.

paymentList=List();
for each invoice in PaymentAgainstInvoice[ID == rushPayment]
{
paymentList.add(invoice.ID);
}
//------------------------------------------
//Utilisez plutôt le script suivant
//------------------------------------------
paymentList = PaymentAgainstInvoice[ID == rushPayment].ID.getAll();

Exemple 3:

Voici un autre moyen d’utiliser des fonctions intégrées pour éviter une boucle.

fethcInvoice = Invoice[ID == input.invoiceId];
for each lineitmcount in fethcfrominv.Line_Items
{
contlines = contlines + 1;
}
//--------------------------------------------
//instead use the below script
//------------------------------------------
count=fethcInvoice = Invoice[ID == input.invoiceId].count(ID);

Exemple 4:

Cet exemple de code montre comment éviter des opérations de mise à jour inutiles.

billId = insert into Bill
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];
fetchBill = Bill[ID == billId];
if(patient_Type == "Free")
{
fetchBill.Total_Price=0;
fetchBill.Bill_Status="Closed";
}

//--------------------------------------------
//Au lieu d’utiliser ce code, on peut exécuter le contrôle avant d’insérer les données dans le formulaire Bill. On évite ainsi l’opération de mise à jour inutile. //--------------------------------------------

if(patient_Type == "Free")
{
Total_Price=0;
Bill_Status="Closed";
}
billId = insert into Bill
[
Added_User=zoho.loginuser
Total_Price=Total_Price
Bill_Status=Bill_Status
];

Ressources

Introduction à Deluge

Bonnes pratiques d’application mobile

On peut déterminer et modifier les actions et événements déclenchés, comme un clic sur un enregistrement, un balayage vers la gauche et un balayage vers la droite.
On peut définir les colonnes d’un aperçu et d’une vue détaillée selon le contexte de l’application.
Un logo personnalisé est téléchargeable dans les applications.
Les applications sont personnalisables et publiables séparément, hors ligne, pour les utilisateurs et les clients.

Bonnes pratiques d’utilisation et d’expérience utilisateur

Formulaires

Une disposition multicolonne sert à scinder un formulaire en parties plus petites.
Des sections permettent de regrouper logiquement des champs selon le contexte.
La taille de champ et la position des libellés sont modifiables.
Des textes ou des bulles d’aide visent à aider les utilisateurs à comprendre les données à saisir dans un champ.
On peut ajouter des messages de réussite pour confirmer les envois.
Configurez des notifications par courriel ou SMS à envoyer aux utilisateurs pour certaines actions.
L’affichage de messages et d’alertes appropriés vise à fournir une assistance visuelle.

Rapports

Personnalisez des messages contextuels à contenu pertinent pour les afficher dans les rapports.
L’aperçu rapide d’un rapport ne doit contenir que les colonnes les plus importantes et pertinentes.
On peut ajouter d’autres informations à l’aperçu rapide et les regrouper logiquement avec des blocs.
Gelez les colonnes d’un rapport pour maintenir le contexte de l’enregistrement lors du défilement.
La mise en forme conditionnelle permet de souligner des enregistrements selon certains critères.
Simplifiez les actions fréquentes avec des boutons d’action personnalisés et placez-les en en-tête.
On peut définir des messages de confirmation avant d’exécuter les boutons d’action personnalisés.
Des dispositions et des modèles servent aussi à personnaliser l’apparence des enregistrements selon le contexte.

Pages

Un tableau de bord vise à fournir un aperçu complet des processus de l’application. On déconseille de le surcharger d’éléments pour ne pas le rendre difficile à comprendre par les utilisateurs.
On peut créer plusieurs pages selon le contexte.

Navigation dans les applications

Des thèmes permettent de modifier la navigation supérieure, à gauche et dans la grille.

Si vous avez d’autres questions, veuillez nous contacter.