J'ai plusieurs contextes Camel dans mon projet et j'aimerais documenter les routes si possible de manière inverse, car nous voulons garder la documentation à jour en rapport avec le contexte. Quelle serait la meilleure approche?Documentation de Routes Camel
Nous avons tendance à concevoir les routes à l'avant et les modéliser en utilisant l'iconographie du EIP book. Cela nous donne un guide pour ensuite tester nos routes. Est-ce que vos itinéraires changent vraiment souvent que l'ingénierie inverse est nécessaire? Nous cherchons lentement à construire une interface utilisateur dynamique pour nos routes - mais ce ne sera pas avant 2011 :)
Vous pouvez simplement ajouter de la documentation dans le DSL réel, puis avoir des outils ou quoi que ce soit qui extrait cette route et Documentation. Dans le DSL XML de printemps, vous devriez être en mesure d'ajouter des éléments aux EIP de la route. Vous pouvez également également ajouter des commentaires XML généraux.
De plus, comme mentionné ci-dessus, certains outils GUI sont aussi ce que certaines personnes veulent utiliser. Alors souvent, le diagramme visuel des routes utilisant les icônes EIP est la documentation. FuseSource est en train de construire un outil d'interface graphique appelé FuseSource Rider. Ce sera en beta publique plus tard ce mois-ci.
à Apache Camel il y a un certain outillage Maven pour générer des diagrammes graphiques http://camel.apache.org/visualisation.html
La documentation originale a été réalisée en utilisant la notation de modélisation des processus métier (BPMN) et beaucoup de travail a été fait, les routes ne sont plus compatibles avec le BPMN. Notre problème vient du fait que l'un des membres de l'équipe est parti et n'a pas eu le temps de documenter le travail qu'il a fait. Les routes ne sont pas complètement définies car il s'agit d'un très gros projet (projet de recherche de l'Union européenne) et les spécifications changent à mesure que de nouvelles exigences sont identifiées. – Monachus