CONSIGNES: Defaulting

 Cet article regroupe les consignes concernant les valeurs à utiliser par défaut et que doivent suivre les développeurs de VISEO qui travaillent avec moi. Il m'a paru intéressant de les regrouper ici en un article afin qu'elles soient très largement disponibles.

Le "defaulting" de Mulesoft est en général très bon. Il y a néanmoins quelques trous dans la raquette et si vous suivez les consignes données ci-dessous vous vous éviterez bien des ennuis. Cet article a vocation à être régulièrement enrichi, au fur et à mesure de nos "découvertes". Commençons:

Reconnexion

C'est le defaulting de Mulesoft le plus étrange, provoquant, selon mon expérience 50% des bugs rencontrés en production. Par défaut, l'option de reconnexion est fixée par Anypoint Studio à "None", c'est à dire que si la connexion tombe (qu'elle soit HTTP, VM, Object Store, SFTP, etc, etc), elle ne pourra pas être rétablie. Un redémarrage du serveur est alors inévitable. Non seulement ce defaulting est aberrant, mais le fait même de simplement proposer cette option, nécessiterait une explication que je n'ai pas ! Cerise sur le gâteau, il existe une option "Standard" qui comme son nom l'indique ferait une excellente valeur par défaut! Bref, n'oubliez JAMAIS de changer cette option sur tous les objets de configuration (volet "Advanced"):

La valeur des autres paramètres est plus dépendante de votre contexte. Mais les valeurs fournies par Anypoint Studio sont généralement adaptées.

Si vous tentez de vous connecter avec un outil/ressource dont le fonctionnement peut présenter de longues périodes de panne, optez alors pour l'option "forever" en augmentant la valeur du paramètre fréquence à quelque chose de l'ordre de la minute afin d'éviter de mitrailler les systèmes, de requêtes:

J'insiste lourdement sur ce défaulting car il a tout du piège dangereux: en développement, voir en tests utilisateurs, tout semblera bien se passer, car le système ne restera probablement pas actif suffisamment longtemps pour que le connexion tombe. En production, en revanche, cela arrivera fatalement.

Si quelqu'un a une idée sur l'intérêt que peut avoir l'option "None", qu'il prenne contact avec moi. Je l'en remercie d'avance.

Replica Count

Mulesoft insiste, aussi bien dans la documentation, que dans les formations et les forums, sur le fait qu'il faut monter au moins 2 réplicas pour chaque application, afin de garantir une meilleure continuité de service. Je souscris pleinement à ce conseil. Mais pourtant, lorsque l'on déclare une instance, c'est systématiquement 1 réplica qui est proposé par défaut. Donc n'oubliez pas, même dans les environnements qui ne sont pas en production:

1. de demander au moins 2 réplicas (c'est généralement suffisant)
2. de cocher l'option "Run In Runtime Cluster Mode" (bas de la page) qui est décoché par défaut.

Sur CloudHub 1.0, c'est déjà une sage précaution. Sur CloudHub 2.0, c'est carrément une nécessité: car la persistance de VM et d'Object Store en dépend ! En effet, tout le contenu de ces deux mécanismes est perdu dès qu'il n'a plus d'instance active. Moralité, si vous redéployez, vous perdez tout ! Que de drames, de faux bugs et de suspicions ai-je rencontré sur les projets parce que les caches ou des données dynamiques de configuration "disparaissent" quand un développeur uploade une nouvelle version.  Mulesoft serait bien inspiré de modifier ce defaulting rapidement.

Le mode Cluster est indispensable avec CloudHub 2.0, non seulement pour assurer la persistence de VM et d'Object Store, mais aussi pour éviter que Mulesoft ne traite "en double" vos fichiers/SFTP et autres scheduler !

Si quelqu'un sait pourquoi Object Store et VM ne sont plus vraiment persistents, sachez que je suis demandeur d'une explication. Cette raison seule me fait préférer CloudHub 1.0 à 2.0 !

Primary Mode Only

Encore un defaulting Mulesoft que j'ai bien du mal à m'expliquer. Toutes Sources de type "On Event" (On new or updated file, On New Message, On New Email) proposent une option "Primary Mode Only" qui n'est jamais cochée par défaut. Noter que les Listeners proposent la même option. Dans le cas des Listeners, le defaulting de cette case à cocher est le bon, même si à l'occasion, il peut être utile ou nécessaire de la changer. 

Dans le cas des composants "On Event", il ne convient pas de systématiquement cocher cette option. Il ne faut le faire de manière systématique que dans le cas ou la simple consommation de la ressource ne provoque pas sa non disponibilité immédiate (comme sa disparition par exemple). C'est le cas en particulier des Sources de type "On New Or Updated File" des connecteurs File, FTP ou SFTP.

En effet, dans le cas de ces Sources, si deux instances Mulesoft sont susceptibles de traiter l'évènement, elles peuvent se faire concurrence. Ce qui revient à traiter l'évènement deux fois. Or dans la quasi totalité des cas, un double traitement entraine des dysfonctionnements. Il faut donc réserver cette fonction à une seule instance de serveur et donc cocher l'option "Primary Node Only".

_____________________________________________________________________

This article brings together the default values that VISEO developers working with me must follow. I thought it would be a good idea to group them together here in one article, so that they are widely available.

Mulesoft's defaulting is generally very good. There are a few holes in the system, however, and if you follow the instructions given below, you'll save yourself a lot of trouble. This article is intended to be regularly enriched, as and when we make "discoveries". Let's get started:

Reconnect

This is Mulesoft's strangest defaulting, causing, in my experience, 50% of the bugs encountered in production. By default, the reconnection option is set by Anypoint Studio to "None", i.e. if the connection drops (whether HTTP, VM, Object Store, SFTP, etc, etc), it cannot be re-established. A server restart is then inevitable. Not only is this defaulting aberrant, but the very fact of proposing this option would require an explanation that I don't have! The icing on the cake is that there is a "Standard" option which, as its name suggests, would make an excellent default value! In short, NEVER forget to change this option on all configuration objects ("Advanced" pane):

The values of the other parameters are more dependent on your context. However, the values provided by Anypoint Studio are generally appropriate.

If you're trying to connect with a tool/resource that may be subject to long periods of downtime, then you should opt for the "forever" option, increasing the value of the frequency parameter to something on the order of a minute, to avoid peppering systems with requests:

I'm insisting heavily on this defaulting because it's a dangerous trap: in development, or even in user testing, everything will seem to be going well, as the system will probably not remain active long enough for the connection to fall out. In production, on the other hand, this is bound to happen.

If anyone has any ideas about the usefulness of the "None" option, please get in touch with me. Thank you in advance.

Replica Count

In its documentation, training courses and forums, Mulesoft insists on the need to set up at least 2 replicas for each application, to guarantee better continuity of service. I fully subscribe to this advice. However, when an instance is declared, 1 replica is systematically proposed by default. So don't forget, even in non-production environments:

1. request at least 2 replicas (this is generally sufficient)
2. check the "Run In Runtime Cluster Mode" option (bottom of page), which is unchecked by default.

On CloudHub 1.0, this is already a wise precaution.On CloudHub 2.0, it's an absolute necessity: because VM and Object Store persistence depend on it!Indeed, all the content of these two mechanisms is lost as soon as there is no longer an active instance.If you redeploy, you lose everything! What drama, false bugs and suspicions I've encountered on projects because caches or dynamic configuration data "disappear" when a developer uploade a new version.  Mulesoft would be well advised to change this defaulting quickly.

Cluster mode is essential with CloudHub 2.0, not only to ensure VM and Object Store persistence, but also to prevent Mulesoft from "duplicating" your files/SFTP and other schedulers!

If anyone knows why Object Store and VM aren't really persistent anymore, I'd love to hear about it. This reason alone makes me prefer CloudHub 1.0 to 2.0!

Primary Mode Only

Another Mulesoft defaulting that I'm having trouble explaining to myself. All "On Event" Sources (On new or updated file, On New Message, On New Email) offer a "Primary Mode Only" option which is never checked by default.Note that Listeners offer the same option.In the case of Listener, the default setting of this checkbox is the correct one, although it may occasionally be useful or necessary to change it.

In the case of "On Event" components, this option should not be systematically checked. It should only be systematically ticked if the simple consumption of the resource does not result in its immediate non-availability (e.g. its disappearance).This is particularly the case for "On New Or Updated File" sources on File, FTP or SFTP connectors.

Indeed, in the case of these Sources, if two Mulesoft instances are likely to process the event, they can compete with each other. This means processing the event twice. In almost all cases, double processing leads to malfunctions. You should therefore reserve this function for a single server instance, and check the "Primary Node Only" option.