MuleSoft Crowd Release par rapport à Mule 4

MuleSoft Crowd et Mule 4 sont sortis depuis un moment. Crowd était sorti vers mai 2017, et Mule 4 a été libéré à la fin de 2017.

De nombreux clients Mule existants ont été mis à niveau vers la version Crowd. Cependant, plus de nouveaux clients ont adopté Mule 4. Cependant, même avec l'adoption rapide, j'ai remarqué que beaucoup de gens ne sont toujours pas clair sur les différences entre les deux.

Dans ce post, je vais mettre en évidence les principales différences entre Mule 4. Je vais mettre en évidence quelques fonctionnalités principales dans chaque version. Je prévois d'élaborer plus sur ces fonctionnalités dans les prochains messages.

Les détails de chaque version sont dans les notes de version. Cependant, les notes de publication peuvent parfois être difficiles à lire. Voici un aperçu des principales différences:

Foule Communiqué de presse

Jetons un coup d'œil à la libération de la foule en premier. Tout en haut, La sortie de foule est encore 3.x.x . Pour les utilisateurs de Mule 3.x, le changement le plus notable est le gestionnaire d'API 2.x le nouveau Design Center et le serveur amélioré Exchange . La version Crowd utilise maintenant API Manager 2.x https://docs.mulesoft.com/api-manager/v/2.x/

La diffusion de la foule favorise le développement et le déploiement d'API de cycle de vie complet. Voici les principales étapes pour développer une API:

Veuillez noter: les étapes suivantes sont pour développer une API complète avec implémentation, pas seulement le proxy API, ce qui est un cas légèrement plus simple.

Développement :

• Étape 1 : lancer le design RAML dans Design Center. Il peut s'agir d'un fragment RAML (types de données etc.) ou d'une spécification API complète
• Etape 2 : publication de RAML vers Exchange
• Etape 3 : télécharger la spécification API depuis l'échange (ou l'importer directement dans studio), et développez votre flux d'API comme vous le faites normalement auparavant.

Déploiement :

Avant de pouvoir déployer votre API en Runtime, vous devez obtenir les paramètres pour la découverte automatique de l'API (nom et version de l'API) à partir de l'API Manager (2.x). Dans le passé, vous pouvez donner des valeurs arbitraires (à condition qu'elles soient uniques). Vous devez maintenant obtenir ces valeurs à partir du gestionnaire d'API. sinon, le gestionnaire d'API ne reconnaîtra pas votre API.

Veuillez noter qu'APIM 2.x différencie désormais les environnements pour les API. C'est un grand pas en avant pour soulager les maux de tête de versioning de l'API chaotique avec l'ancien APIM 1.x (voir https://blogs.perficient.com/2017/10/04/what-is-in-a-mule-api- version /)

Poursuivant les étapes de développement ci-dessus:

• Étape 4 : récupérez le nom et la version de l'API, comme indiqué dans la capture d'écran (sur le côté droit de la console API) à votre projet (tag ). Comme meilleure pratique, stockez ces paramètres dans le fichier de propriétés spécifique à l'environnement.
• Étape 5 : terminez les flux du projet et déployez-le vers l'API pour l'exécution. Maintenant, l'API Manager 2.x devrait voir l'API s'exécuter (enregistrée).

Promouvoir l'API vers des environnements plus élevés

Comme mentionné ci-dessus, maintenant APIM 2.x gère les API pour chaque environnement. Il applique également un processus de promotion systématique des API vers les environnements supérieurs.

Pour promouvoir une API, depuis la console API Manager, trouvez votre API dans l'environnement DEV, vous verrez un bouton "Promouvoir depuis l'environnement". , il va générer les nouveaux paramètres (nom de l'API, version) pour la cible (UAT, PROD etc). Copiez ces paramètres et placez-les dans vos fichiers de propriétés spécifiques à l'environnement. Vous pouvez maintenant déployer votre API dans l'environnement supérieur.

Mule 4:

Mule 4 est une version majeure. En plus de API Manager 2.x (identique à Crow), il a également changé le format d'empaquetage en .jar. Le projet doit être déployé à l'exécution 4.x. Comme un effet secondaire, les projets Mule 3.x et Mule 4 ne sont plus compatibles les uns avec les autres.

Mule 4 introduit de nombreux autres nouveaux changements. Quelques-uns comprennent:

• Vous devez utiliser Studio 7 pour développer le projet Mule 4.
• Le projet est présenté sous la forme .jar; Les structures de projet sont modifiées, et il utilise lourdement YAML pour de nombreux artefacts
• Dataweave utilise la version 2.0, qui a beaucoup de nouvelles fonctionnalités puissantes.
• Il supporte l'exception avec "try-catch" comme Java.
• support de diffusion de données, qui (soi-disant) rend obsolète de nombreux transformateurs confus (json-to-object, object-to-json).
• Oh, un petit détail importé: API auto-discover utilise un ID API unique ( montré dans la capture d'écran ci-dessus).

Principaux avantages:

Crow Release fonctionne toujours sur Mule 3.x. Il utilise APIM 2.x, Design Center et Exchange pour gérer le cycle de vie complet du développement de l'API.

Mule 4 Release est basé sur la version Crowd, mais il utilise le runtime Mule 4.x . Outre de nombreuses nouvelles fonctionnalités, vous devez utiliser Studio 7, et le projet est empaqueté en tant que .jar et les fichiers projet ne sont plus compatibles entre Mule 3.x et 4.x.